Beau Cronin wrote:
If u are using Pessimistic Lock policy , any call on a CMP entity (even if the method is a get* one) will register the bean instance in the current Tx and so the bean will be locked. I mean, if u have an AccountBean for example and 1 client calls <tx begin>bean1.getName(); bean2.getName(); <tx end> and another client (same or separate JVM) <tx begin>bean2.getName(); bean1.getName()<tx end>, u will get a deadlock eventually.Muntean Horia wrote:Beau Cronin wrote:I have a Swing app which is essentially single-threaded, accessing the server in the usual way through a session facade. I'd like to do some background loading of certain data for performance reasons, but when I try to do this by using a separate thread (and separate session instance), I get various transaction collision problems if these two threads access the server at the same time.
I'm obviously missing something here--shouldn't different remote client threads from the same client be able to access JBoss simultaneously in the same way that entirely different clients can? I.e., shouldn't they spawn separate transactions which are scheduled appropriately by JBoss?
Any clarification appreciated,
Beau Cronin
-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Try to do the same thing u are doing with 2 threads in the same VM, in 2 different JVMs. And (as I suspect it would be) if u get the same collisions (tx deadlocks?), your problem resides at the server side.
The problem does not occur when multiple users (i.e., many different clients, each with its own JVM) are on the system. This leads me to believe it is not a fundamental server-side problem. It only occurs when two threads from the same client make simultaneous calls. Please see my reply to Alex Loubyansky for the relevant stack traces.
Thanks,
Beau
Regards, Horia ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
There are some solutions over this:
1. Order carefully the calls to your entity beans.
2. In 3.2. (some say this is in 3.0.x also but I never tried it here) there is a <read-only> method level tag that marks a certain method of an entity as being RO so the bean won't be blocked by the calling TX.
2. Try the Instance Per Transcation container policy.(but here commit option A doesn't make any sense and logical data consistency is not guaranteed)
3. In 3.2. there is a OptimisticLock policy implementation.(AFAIK commit option A doesn't make sense here either. yet.)
Regards,
horia
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
