Re: Is the implementation of lock(LockModeType.READ) correct?

2009-02-21 Thread Philip Aston
No, I don't agree. You could re-order these transactions so they didn't overlap with the same result. That is, I1 could complete Tx1, before I2 begins Tx2. The Bank's rules on handling the joint account is flawed, and it essentially lets A&B overdraw the account by its current positive balance.

Re: Is the implementation of lock(LockModeType.READ) correct?

2009-02-21 Thread David Ezzio
Hi Philip, Actually, I was not thinking of proof by implementation, but rather a mathematical proof. As it turns out, I think there is a counter-example that disproves the viability of your suggestion. It's an example that is only slightly different from the one that we have discussed. For the

Re: Entity Version Fields and Bi-Directional One-to-Many Relationships with Cascade Merge

2009-02-21 Thread MiƂosz Tylenda
Jason, I have done some testing and saw version fields behaving like I supposed earlier. - If you persist a new Person, its Address version does not change. - If you modify Person's property, its Address version does not change. It does not matter whether you em.find() the Person or you em.find