DefaultRevisionEntity, @RevisionNumber and strictly-increasi

[dorlov]

Hi Adam!

I found that Envers make some assumption about @RevisionNumber that itself doesn't satisfy in DefaultRevisionEntity.

@RevisionNumber comment states that

Values of this property should form a strictly-increasing sequence of numbers.

but DefaultRevisionEntity defines it as

public class DefaultRevisionEntity {
 @Id
 @GeneratedValue
 @RevisionNumber
 private int id;

that in common case could be not increasing at all (id generator doesn't provide strictly-increasing sequence guaranties).

So is it possible that for example I request last revision of entry, but this last revision doesn't correspond to last changes of that entry?

Den

[adamw]

Hello,

well, it depends on what database you are using ... usually it's auto_increment (mysql) or an identity column, which form an increasing sequence.

But yes, if the number are out of sequence, then the results may be wrong.

Adam

[dorlov]

But even in the case of auto_increment column we can get problems. As I understand auto_increment column get its value and increments internal counter during transaction.

Let consider situation with two transactions: tr 1 and tr 2. Tr 2 was started and get its revision after tr 1, but was committed before tr 1. So we again get situation when max revision doesn't correspond to last object change.

Am I correct?

Den

[dorlov]

But even in the case of auto_increment column we can get problems. As I understand auto_increment column get its value and increments internal counter during transaction.

Let consider situation with two transactions: tr 1 and tr 2. Tr 2 was started and get its revision after tr 1, but was committed before tr 1. So we again get situation when max revision doesn't correspond to last object change.

Am I correct?

Den

[adamw]

Hello,

well, yes, you are partially right :). In your scenario it's really hard to say which revision should be "first". But, this shouldn't cause problems, because if both transactions modify the same entity, one of them will be rolled back, because of a conflict.

Adam

[dorlov]

But for the case of 2 txs that don't overlap considered situation is probable. Is it so?

I have scenario where my occasionally connected client remember max revision. Next connect client retrieve all object changed since previous connect. So for considered scenario I could lose one of the transactions.

Den

[adamw]

In case of 2 txs that don't overlap I think this depends on the DB, if it locks whole rows or individual cells. I'm not an expert on DBs, but as far as I remember it's normally row-locking - but you would have to check that for your DB.

But in theory, if it's cell-level locking, then yes, it is possible. And if your client retrieved the revisions after the second tx commited, but not yet the first, then it would miss one revision.

How to solve this in such a scenario I don't know really :)

Adam

[adamw]

(Unless the client simply holds the list of revision numbers it has already received, or, as an optimization, a list of revision numbers in the last week - then you wouldn't get any TX problems)