Rickard, Daniel, > Logical object yes, physical object no. I.e. there may be several > instances at once that map to the same object identity. If changes are > made concurrently to several instances there will be transaction > rollbacks of course.
Actually, transactions need not be rolled back - depending on the deployer's use of the Container's strategy when performing updates. For example, if the concurrency was pushed to the database, the Container can just blindly issue updates without worrying about corrupting data. But in the case being discussed, the Container would need ensure consistency; possibly by means of issuing verified updates. > > > Should I picture the container dressing up a directory of > > all > > fields with their PK and creating links on PKs when two fields are equal. > > > I did not get that allegory... it's really very very simple... several > instances, same data.. nothing strange at all really. Again, probably a useful analogy is that though there are possibly many instances of the entity bean implementation class (with possibly the same sets of data), what is "unique" among these different instances is not the pk - but the current transactional context. That is, the transaction context each of these instances execute in is unique. Which is how most EJB vendors implement optimistic concurrency at the Container level - by having the ability to dispatch on both the pk and the (unique) transaction context for that instance. -krish =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
