Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Clustered environments Javers will incorrectly version records. #877
JV_SNAPSHOT table example.
What is should look like:
The logic seems to be select the max pk and then find the version number from that.
I think here you are assuming the numbers are always representative of insert order. But there is many cases where this would not be true. In this case since the first node that did the insert was ahead in snapshot_pk, subsequent inserts are always ignored for selection as the latest version.
Seems that in clustered environments Javers should not use the Sequence Allocation trick, see https://github.com/javers/javers/blob/master/javers-persistence-sql/src/main/java/org/javers/repository/sql/session/Sequence.java#L12
Without the Sequence Allocation trick, primary keys ordering would be guaranteed by the database sequence.
Sequence nextval call should be inlined in the
Just some general questions about this fix.
It appears that you were multiplying the sequence number by a hundred as some sort of caching mechanism.
Meaning I need to promote the JV_SNAPSHOT_PK_SEQ to SNAPSHOT_PK + 1?
Are there any other Sequences I need to promote? Your change appears to be to very generic code, so I assume you changed all the sequences to use this behaviour?
While I manage the JV tables/sequences (I've disabled schema management), I didn't see code in the commit that would automatically promote other sequences in the managed cased.
Looks like the bigger problem is in this line in
So when SEQUENCE_ALLOCATION trick is discontinued, db sequences should be multiplied by 100. I need to check it. For now, version 5.7.1 has to be withdrawn.