elkner, Are you sure?
Well, at least if you use a kind of optimistic locking via @Version one of both should fail and the failed transaction should be rolled back (of course only, if your are not chomping the Exceptions, which automatically trigger the rollback ;-)). Just make sure, that you call em.flush() after merge to be able to catch the exception inside the bean method (i.e. actually before the JTA is finished).
If the method does just a simple merge of a simple bean, it might be even relyable without having a NEW TA, since hibernate should catch the problem on flush via @Version.
But, catch the Exception not all. I want to solve the clash about protect the Entity Instance object from concurrent access. Like synchronized keyword in regular JavaBean, to limited only one can access the object at the same time.
this complexion also about some resource, like Queue. In PTP mode, we want only one send the message to the Queue at the same time.
REQUIRES_NEW?The annotated method is executed within a newly generated transaction.If the caller method is already in a transaction, it is suspended.
@TxSynchronized : When a @TxSynchronized member method is called, the object instance's lock monitor is held for the duration of the transaction, until it commits or rolls back. When a @TxSynchronized annotated static method or constructor is invoked, the Class's lock monitor is held for the duration of the transaction. This lock works like synchronized, in that the lock is only acquired when a tagged member is called.
I think it can solve the clash.
Not sure, what you are trying to accomplish with it, however, where do you know,
1) that's the EM has only ONE instance of an SLSB?
2) that there is only one EM, which "manages" the SLSB?
3) that not another instance of something accesses your bean from within another ClassLoader?
4) Scaleability is not an issue for you ?
Even if it would work like synchronized, what do you expect/does it buy you? Do you expect, that the method gets always an entity passed, with the latest committed state? If so, I think you have wrong assumptions...
So, use @Version? Use Version field each table? but applications that use more than one
Version property or field will not be portable.
elkner, Should you give me a example about using @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) ,@TxSynchronized,@Version?