|Oops, I didn't expect that! Not that I really have a deep
|understanding of the code, but the problem seems not to be with
|the locking of the context, but with your beans not beeing marked
it is in the mutex... it is a JBOSS bug...
marc
|as reentrant, thus only one client can access a bean at any given
|time.
|
|The code there does not distinguish between a method executing in
|the right transaction and a method executing without a
|transaction at all. I just can't remember if the EJB specs are
|clear about non reentrant beans accessed outside a transaction
|(have to read that thing even once more :-(), but the implemented
|behaviour is on the safe side.
|
|Not beeing 'reentrant' allows the bean provider to write simple
|code without synchronizing and all the complicated issues, that
|arise when you must consider concurrent access (and synchronizing
|etc. is forbidden anyway in EJBs). See spec 1.1 9.1.12. Only when
|you have 'callback' in mind, you should allow reentrant beans.
|
|In your case, I'm pretty sure, that the conflict is NOT caused by
|callbacks, but by several clients attempting to concurrently
|access your beans. Within a transaction this clearly must be
|blocked (or, as the specs require, 'solved' with a
|RemoteException).
|
|But in your case, only reading the beans outside a TX, where the
|gotten state must be considered invalid, wrong, old, outdated
|anyway, it should be no problem at all to allow concurrent
|access.
|
|So, to continue your tests, declare your beans as 'reentrant'!
|
|What's not nice with this workaround is, that a reentrant bean
|might get accessed inside one and the same transaction from
|different clients (in the rare case, where a superclient starts a
|transaction, then spawns new threads (inheriting the TX) for
|different activities, do you know other scenarios?). So it might
|be better, to change the code to sort out access outside a TX
|allowing concurrency even when the bean is not reentrant??
|
|And, besides, the code suffers from the same problems as I told
|you in my last mail to this thread: not waiting and thus going
|into a tight loop with tons of messages and eating up CPU time;
|maybe, it would be better to throw the RemoteException the spec
|asks for?
|
|> Why is it locking for readonly bean? Why does it need to do it?
|
|For the transactional case I told you already; for
|nontransactional access I propose ignoring the reentrant flag
|(only if the spec does not explicitely disallow it or someone can
|point out the danger with it).
|
|> The effects are only marginal and hardly detectable at low loads.
|> It is more pronounced at higher loads and as the table size
|> increase it goes into a real amplifying loop where the beans wait
|> and take longer to return and that in turn cause the lock to be
|> longer and so on.
|
|Would be 'solved' by an Exception and should be considerably
|better, when the server actually would wait instead of going into
|the tight loop.
|
|> Strange that the method does not check for read-only attribute
|> either? Why is that?
|
|As of the spec there is no 'readonly' method, name it: the spec
|sucks?
|
|best regards
|Georg
| ___ ___
|| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
||_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
|
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
