Hi Georg,
You said:
>If you cannot use the QueuedPessimisticEJBLock (which is usually the
>case when you need concurrent access to CMP EBs), and you need to
>synchronize your EBs, you can use the "row-locking" setting in the
>jbosscmp-jdbc.xml config file (in defaults or per EB) and let the
>database handle the synchronization.
>
>
I just want to repeat this to be sure I got it right.
1.Instance Per Transaction CMP 2.x EntityBean (NoLock) modified with
<commit-option> A
2.No more <read-only> tags at method level ('cause they are deprecated
anyway)
3.<row-locking> set to true for the EBs I want to sync.
Well, if I have this scenario:
1. Client C1 calls a facade method that updates U1, U2, ...., U7 (in
this order) EBs
2. Client C2,C3,C4 call another facades method that only sums some
number field for the U1, U2, .., U7 (no updates) EBs in the same time C1
updates those beans.
My question is: what is the value of the U1 data viewed by C2 client?
Is this value the value before U1 entered the C1 TX? (by analogy - a
read-commited isolation). How can this be with <commit-option>A? Does
jboss save the bean fields before entering a TX?
Or this is the value that U1 currentry has, even if C1 TX isn't finished?
Or I can't user <commit-option>A in this scenario and by dropping this
option I would loose the cache bliss?
Or maybe I should test it and see what I get. :)
Thanks.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
