>>>>> "Georg" == Georg Rehfeld <[EMAIL PROTECTED]> writes:
Georg> Hello 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!
Georg> Ah, at least one person giving it a try, thanks. I should have done
Georg> this on my own, but I'm just too busy reading and understanding
Georg> JBoss code (and really, I have more than enough work to do USING
Georg> JBoss and not trying to understand it in depth, my boss is very
Georg> unhappy with me the last days).
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.
>> However sql statements always rollback after the bean gets invoked
>> (creaters, finders, getters/setters anything) without a transaction
>> context.
Georg> Oops, that again comes unexpected for finders and getters. Do you
Georg> have isModified() implemented in your beans? If not, would you give
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!
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).
Georg> it another try, implement isModified() and only access your beans
Georg> via finders and getters? Does the rollback show up then? If so,
Georg> would you please send stack traces to this list (or to me)?
Hmmm, no exceptions going on and I don't run a debugger, but here's some
postgresql output from a fresh deploy and browsing the index page:
Jun 6 18:31:50 dev3 postgres[15851]: [1] DEBUG: connection: host=127.0.0.1 user=shop
database=shop
Jun 6 18:31:50 dev3 postgres[15851]: [2] DEBUG: InitPostgres
Jun 6 18:31:50 dev3 postgres[15851]: [3] DEBUG: StartTransactionCommand
Jun 6 18:31:50 dev3 postgres[15851]: [4] DEBUG: query: set datestyle to 'ISO'
Jun 6 18:31:50 dev3 postgres[15851]: [5] DEBUG: ProcessUtility: set datestyle to
'ISO'
Jun 6 18:31:50 dev3 postgres[15851]: [6] DEBUG: CommitTransactionCommand
Jun 6 18:31:50 dev3 postgres[15851]: [7] DEBUG: StartTransactionCommand
Jun 6 18:31:50 dev3 postgres[15851]: [8] DEBUG: query: begin
Jun 6 18:31:50 dev3 postgres[15851]: [9] DEBUG: ProcessUtility: begin
Jun 6 18:31:50 dev3 postgres[15851]: [10] DEBUG: CommitTransactionCommand
Jun 6 18:31:50 dev3 postgres[15851]: [11] DEBUG: StartTransactionCommand
Jun 6 18:31:50 dev3 postgres[15851]: [12] DEBUG: query: rollback
Jun 6 18:31:50 dev3 postgres[15851]: [13] DEBUG: ProcessUtility: rollback
Jun 6 18:31:50 dev3 postgres[15851]: [14] DEBUG: CommitTransactionCommand
Jun 6 18:31:50 dev3 postgres[15851]: [15] DEBUG: StartTransactionCommand
Jun 6 18:31:50 dev3 postgres[15851]: [16] DEBUG: query: begin
Jun 6 18:31:50 dev3 postgres[15851]: [17] DEBUG: ProcessUtility: begin
Jun 6 18:31:50 dev3 postgres[15851]: [18] DEBUG: CommitTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [19] DEBUG: StartTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [20-1] DEBUG: query: select id from categories
where expose = true and id in (select category_id from product_categories) order by
Jun 6 18:39:00 dev3 postgres[15851]: [20-2] priority
Jun 6 18:39:00 dev3 postgres[15851]: [21] DEBUG: ProcessQuery
Jun 6 18:39:00 dev3 postgres[15851]: [22] DEBUG: CommitTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [23] DEBUG: StartTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [24] DEBUG: query: rollback
Jun 6 18:39:00 dev3 postgres[15851]: [25] DEBUG: ProcessUtility: rollback
Jun 6 18:39:00 dev3 postgres[15851]: [26] DEBUG: CommitTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [27] DEBUG: StartTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [28] DEBUG: query: begin
Jun 6 18:39:00 dev3 postgres[15851]: [29] DEBUG: ProcessUtility: begin
Jun 6 18:39:00 dev3 postgres[15851]: [30] DEBUG: CommitTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [31] DEBUG: StartTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [32] DEBUG: query: select * from categories
where id = 1
Jun 6 18:39:00 dev3 postgres[15851]: [33] DEBUG: ProcessQuery
Jun 6 18:39:00 dev3 postgres[15851]: [34] DEBUG: CommitTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [35] DEBUG: StartTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [36] DEBUG: query: rollback
Jun 6 18:39:00 dev3 postgres[15851]: [37] DEBUG: ProcessUtility: rollback
Jun 6 18:39:00 dev3 postgres[15851]: [38] DEBUG: CommitTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [39] DEBUG: StartTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [40] DEBUG: query: begin
Jun 6 18:39:00 dev3 postgres[15851]: [41] DEBUG: ProcessUtility: begin
Jun 6 18:39:00 dev3 postgres[15851]: [42] DEBUG: CommitTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [43] DEBUG: StartTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [44] DEBUG: query: select * from categories
where id = 4
Jun 6 18:39:00 dev3 postgres[15851]: [45] DEBUG: ProcessQuery
Jun 6 18:39:00 dev3 postgres[15851]: [46] DEBUG: CommitTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [47] DEBUG: StartTransactionCommand
Jun 6 18:39:00 dev3 postgres[15851]: [48] DEBUG: query: rollback
Jun 6 18:39:00 dev3 postgres[15851]: [49] DEBUG: ProcessUtility: rollback
Jun 6 18:39:00 dev3 postgres[15851]: [50] DEBUG: CommitTransactionCommand
What happened here is that a jsp called a taglib, IterateCategories, which in
turn called findAllWithProducts on a CategoryHome without a transaction, which
executed a select and returned a dozen or so Integer primary keys (I cut the
log to the first two), jboss then instantiated the CategoryBean objects and
called ejbLoad on them, which executed more selects. All selects we're
rolled back - no harm done.
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).
I did try an experiment with the following transaction attributes:
<method>
<ejb-name>Contact</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Supports</trans-attribute>
<method>
<ejb-name>Contact</ejb-name>
<method-name>setName</method-name>
</method>
<trans-attribute>Required</trans-attribute>
...and using beanshell (http://www.beanshell.org), I manually executed the
following while watching the database:
% ContactHome ch = (ContactHome) Portable...
% Contact c = ch.findByName("Respond2");
% c.setName("XYZ");
// update and commit executed just right
% c.setAddress("123");
// update but then rollback, "address" field out of sync
% c.setName("Respond2");
// runs update and commit, "address" now in sync
Georg> My suggestion (no TX + reentrant) was really ONLY for pure readonly
Georg> access to beans, NEVER attempt to create, update or delete a bean
Georg> without a TX!
I definately plan on setting Required on create and set* (too bad
<method-name>set*</method-name> isn't in the spec). This app is 99%
read-only, so the only method I really had to set Required is one called
"createOrder" in a session bean.
At the moment I've been trying to use a UserTransaction in a client (beanshell
scripts)... dies on ut.begin with "UT factory lookup failed:
javax.naming.CommunicationException: Can't find SerialContextProvider" (lookup
"UserTransactionSessionFactory" fails in ClientUserTransaction) - any ideas?
Thanks
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
