check duplicate message before enqueue

[sonus21]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes: #259

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Unit Test
• Integration Test
• Reactive Integration Test

Test Configuration:

• Spring Version
• Spring Boot Version
• Redis Driver Version

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[hyokwangryu-lunit]

Hello @sonus21,
This PR includes a feature I need urgently—would you be able to review and merge it soon?
And, Would you mind updating enqueueUniqueIn as well?

[Tsar]

But this is not really atomic: if 2 same messageId are enqueued at the same time using this method, then both may pass the check and both will be enqueued.

I have checked how uniqueness is implemented in db-scheduler.
Basically, the logic looks like this:

try {
   if (already queued)
      return false
   insert to queue  // (!!!) id is unique in DB schema, so the query will fail if it tries to insert duplicate
} catch (DB exception) {
   if (already queued)  // second check of "already queued"
      return false
   else
      throw exception
}

Can we do something like this here?

[sonus21]

it's not required here, because redis is a single threaded unlike database.

[Tsar]

Okay, but this method does at least 2 separate Redis operations.
If 2 messages are scheduled at the same time, you can't guarantee it will be "isMessageAlreadyExist -> enqueue -> isMessageAlreadyExist -> enqueue", but not "isMessageAlreadyExist -> isMessageAlreadyExist -> enqueue -> enqueue".
Or can you?

[sonus21]

potentially, we can.. i've updated the pr to use setIfAbsent redis command