CMR collection contains a set of related IDs. In your case, each transaction fetches its set of related IDs at the same time. Deleting some item in one tx does not delete it from the CMR collection in another tx.
Phil Shrimpton wrote:
On Tuesday 18 November 2003 15:57, Alexey Loubyansky wrote:
Hi,
Then the problem might occur when clients access *different* orders which share items. The call order.getItems() can be performed at the same time for both clients (w/o locking) as orders are different. But when a shared item is removed by one of the clients, it is still in the other's client collection.
This sounds like my problem. Whats the best way to prevent/detect/workaround the issue
row-locking would help. But it might not be the best option in your case.
It wouldn't.
As Commit option A is giving me a massive performance boost in this part of the system, I am am trying to think of workarounds.
What if, instead of deleting the 'item', I set a 'deleted flag' to true in the ItemEJB, and change the Order.getItems() to Order.getUnDeletedItems(), would that work, or would I just get items in the second 'collection' that have had their deleted flag set by the first client?
Phil
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
