Hi Vinay, hi all,
Oops, I'm verbose again, (not really) sorry.
> I have tried both options. Started without a container
> transaction defined. In which case it kept throwing
> LOCKING-WAITING transactions [from the EntityInstanceInterceptor]
> which says that JBoss is creating a transaction automatically.
Yes, because of the default Required TX attribute.
> Next I changed the ejb-jar to specify the container transaction
> as REQUIRESNEW and as expected it did create a new transaction
> and hence showed the same messages.
Yeah.
> Finally, changed the container transaction to SUPPORTS when it
> stopped locking for the TRANSACTION and started locking waiting
> for the CTX [Context] in the else clause of the
> EntityInstanceInterceptor's invoke method. So there you go.
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
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
