JMS Cache updates in existing transactions

Question

We have two application instances running, with synchronization over JMS. In the following scenario what will be the outome?
- AppInstance1 does changes to Object1 and commits. These changes are sent to the JMS queue.
- AppInstance2 is in the middle of one transaction when it recieves the cache updates. The current transaction include Object1 (which updates are received for).
Does the transaction in Instance2 get aborted upon receiving the cache sync or are the mechanisms at work in TopLink smart enough to merge the non conflicting fields?
Thanks,
Anders,

Answer 1

This depends on your locking mechanism and has little to do with cache-synch. Cache synchronization does not replace the requirement for a locking mechanism.
If you are using no locking, then no matter if you have a single server, multiple servers with or without cache synch, then there is the potential that concurrent transactions can overwrite each others data.
If you are using optimistic locking, then no matter if you have a single server, multiple servers with or without cache synch, your second transaction will get an optimistic lock error and its transaction will be rolled-back.
If you are using pessimistic locking, then there is not much point in using cache synch as you will be accessing the database anyway. The second transaction will block on its read of the object until the first transaction completes, or throw an error on read if using no_wait.
The benefit that cache synchronization provides it that because changes are synchronized between servers the likely-hood of getting an optimistic lock exception is greatly reduced. It can also be used with infrequently updated objects that do not use any locking, or object to which locking is not an issue.