Repository navigation
ARTEMIS-6289 Use AtomicLong instead of synchronized counter in SimpleIDGenerator - #6770
amarkevich wants to merge 1 commit into
Conversation
|
This looks good to me, although That said, I did notice that there's no unit test for |
| public long generateID() { | ||
| return idSequence.getAndUpdate(id -> { | ||
| if (id == Long.MAX_VALUE) { | ||
| // Wrap - Very unlikely to happen |
There was a problem hiding this comment.
I would keep the previous semantics.
|
If making changes here it would make more sense to use AtomicLongFieldUpdater and a single volatile long value instead of creating a new AtomicLong for every instance of this type. |
I'm not sure there would ever be enough instances of |
I'm not sure why one needs to justify good coding practices... |
SimpleIDGenerator
1d89e67 to
4aa20c3
Compare
Perhaps I'm wrong about this, but my understanding is that the main use-case for any field updater is lowering memory use at scale. The main trade-offs being some clunky boilerplate code, the loss of compile-time type safety, and slightly higher per-call overhead. However, if the scale is too low to reap meaningful memory benefits then it seems reasonable to use the standard |
4 participants
No description provided.