-
1. Re: DefaultRevisionEntity, @RevisionNumber and strictly-incr
adamw Apr 29, 2009 9:10 AM (in response to dorlov)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 -
2. Re: DefaultRevisionEntity, @RevisionNumber and strictly-incr
dorlov Apr 30, 2009 1:53 AM (in response to 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 -
3. Re: DefaultRevisionEntity, @RevisionNumber and strictly-incr
dorlov Apr 30, 2009 1:54 AM (in response to 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 -
4. Re: DefaultRevisionEntity, @RevisionNumber and strictly-incr
adamw Apr 30, 2009 3:07 AM (in response to dorlov)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 -
5. Re: DefaultRevisionEntity, @RevisionNumber and strictly-incr
dorlov Apr 30, 2009 4:04 AM (in response to 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 -
6. Re: DefaultRevisionEntity, @RevisionNumber and strictly-incr
adamw Apr 30, 2009 5:06 AM (in response to dorlov)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 -
7. Re: DefaultRevisionEntity, @RevisionNumber and strictly-incr
adamw Apr 30, 2009 5:07 AM (in response to dorlov)(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)