Hi Gerald,
> >> While following the recent "LOCKING-WAITING" threads I've been
> >> experimenting/tuning my beans for concurrency by turning reentrant
on
> >> and setting TX_SUPPORTS. Great improvement!
> ...
> Tell me about it... Friday is my last day of work and I've got to hand
this
> project over to a couple beginner Java programmers, yet I've spent all
> afternoon "tuning" and looking through the jboss source and there's plenty
> more coding to do.
So hopefully this message doesn't come too late?
> I had implemented isModified shortly after realizing that every get was
> executing ejbStore - while keeping jboss moderately busy, postgresql would
> eat 30% cpu executing updates!
Ok, I see.
> I was wrong about the getters (only the setters cause isModified to return
> true...), however the finders still cause rolledback selects (no real
problem,
> just silly looking).
No real problem sounds good.
> From your original mail:
> This may arguably be a bug because the EJB specification (11.6.3) doesn't
> define what the container should do, but after reading it, I get the
feeling
> that it shouldn't rollback.
I agree mostly, but then 11.6.3 is really annoyingly unspecific,
allows the container to do almost anything (there is a "the
list is not inclusive of all possible strategies" sentence)
and leaves the bean developer in the wet ("the enterprise bean
must be written conservatively not to rely on any particular
Container behavior.")
> It looks as though jboss implemented the first
> "possible strategy":
>
> * The Container may execute the method and access the underlying
resource
> managers without a transaction context.
I had a look at TxInterceptorCMT.java and you seem to be right,
the business/home method is invoked without any transaction
context (when requested by Supports, Never and NotSupported) and
there seems to be no attempt to set autocommit to true ... and as
there is no active transaction at all JBoss CAN'T do a rollback
after method invocation.
So the rollback you see in your debug log must come from somewhere
else, might be from your JDBC driver?
> Potentially elsewhere in the app, a similar taglib could execute some
finders,
> then invoke "incrementVisits" without a transaction, which would cause
> isModified to return true, then ejbStore would execute the update, but
jboss
> would rollback (and the bean instance would still have the new values that
> weren't commited to the database).
As I just told, I don't think JBoss is rolling back, it would be
too stupid to do that and leave the out of sync instance in memory,
hey, there may be some subtile errors in JBoss still, but no
sillyness.
But I agree, it might be best to set autocommit to true, would
avoid problems with drivers not knowing how to handle statements
without a TX and should be fairly easy to be implemented (at
least for the gurus here on the list).
As I said before you should NEVER attempt to write a bean
outside a TX, as there is no guarantee at all, that any EJB
server (including JBoss) will actually call ejbStore() (see
spec 9.1.7.1).
9.1.7.1 suggests DB access in the business methods instead, this
should work, if autocommit were on and the bean were not reentrant.
But I would suggest another schema:
- use commit option B
- have your getters and finders Supports
- have your create/remove and setters Required
- mark the bean as reentrant
- access your Entity beans through a Session bean facade
to have declarative Transaction attributes (and business logic);
alternatively use UserTransaction in your clients (does NOT
work with JBoss 2.2.2 yet, but only with the CVS version)
- read without TX for pure display purposes, where reliability
isn't that important, you gain advantage from JBoss caching
the beans state with option B and without TX
- write within a TX, option B forces ejbLoad() before the
business method executes and you have reliable data to
modify; if your modification depends on the actual state
you are free to first read the state then calc and write
the state all within one and the same TX from the session
bean
my very 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
