JdbcStore concurrency bug fix

[the-thing]

Fixes #357

Changes

• sequence numbers' updates happen in their own individual update queries which will prevent overriding each other sequence numbers with stale values

[chrjohn]

hi @the-thing cool, thanks. So your stress test with your changes passes now, I assume. :)

[the-thing]

Yes it does - you should run it. Obviously this relies still on incoming/outgoing sequences being guarded by the appropriate locks, but at least one sequence update will not pollute the other.

[the-thing]

(ETA: now)
(Sampling Rate: 7.84 M/sec)
(JVMs: 0 starting, 0 running, 0 finishing)
(CPUs: 32 configured, 0 allocated)
(Results: 624 planned; 624 passed, 0 failed, 0 soft errs, 0 hard errs)



RUN RESULTS:
  Interesting tests: No matches.

  Failed tests: No matches.

  Error tests: No matches.

[the-thing]

Have a look if it looks any better.

[chrjohn]

I got this: (I stopped execution after some time)

...... [FAILED] quickfix.JdbcStoreStressTest.TwoSendersSequenceTest

  Scheduling class:
    incrementSender1: package group 0, core group 0
    incrementSender2: package group 0, core group 1
    incrementTarget: package group 0, core group 0

  CPU allocation:
    incrementSender1: CPU #8 (package #0, core #4, thread #8)
    incrementSender2: CPU #10 (package #0, core #5, thread #10)
    incrementTarget: CPU #9 (package #0, core #4, thread #9)
    <system>: CPU #11 (package #0, core #5, thread #11)

  Compilation: unified across all actors

  JVM args: [-XX:-UseBiasedLocking, -XX:-TieredCompilation, -XX:+StressLCM, -XX:+StressGCM]
  Fork: #1

      RESULT  SAMPLES     FREQ      EXPECT  DESCRIPTION
  3, 2, 1, 2        2    0.01%   Forbidden
  3, 2, 3, 2   18,341   99.99%  Acceptable

(ETA: in 00:07:50; at Tue, 2025-12-16 12:20:17)
(Sampling Rate: 3.10 K/sec)
(JVMs: 0 starting, 4 running, 0 finishing)
(CPUs: 16 configured, 16 allocated)
(Results: 96 planned; 10 passed, 4 failed, 0 soft errs, 0 hard errs)

[the-thing]

Which Java version did you use to run? And also, stupid to ask, but did you pull the branch changes?

[chrjohn]

Which Java version did you use to run? And also, stupid to ask, but did you pull the branch changes?

Nevermind, I cloned your fork but forgot to switch to the specific branch. ;) Looking better now, thanks. :)
Impressive sampling rate in your output, btw.

[chrjohn]

I meant to ask you yesterday about this when you introduced the IntSupplier... what was the reason for reverting it now?
I thought the reason for introducing it was because the value was obtained when it was used in storeSequenceNumber(). Now it is already fetched in setNextSender/TargetSeqNum().

Probably makes no difference, but just wanted to ask anyway. ;)
Also, I am asking myself if we can't just take the value of next right away? In theory there could be an increment by another thread between cache.setNext... and storeSequenceNumber() with cache.getNext... as parameter. But that's what you probably meant by #1100 (comment)

[the-thing]

I think it is just simpler. Lambda is lazy is it usually better if there is a chance that something will fail or return faster before lambda gets called. (in this case it doesn't matter and shouldn't be there)

You are right about the next value. I will fix it.