The Access Intent strategy is fairly straightforward.
When deploying the entity you specify <select-for-update/> in the EJB
descriptor if you want database locking to occur.
For Oracle a simple FOR UPDATE is appended to the query. For DB2 a
FOR UPDATE WITH RS USE NAD KEEP UPDATE LOCKS is appended to the query.
Oracle is pretty straightforward as at read-committed FOR UPDATEs are
persistent.
For DB2 at RS the additional predicates are required so that the lock
is persistent for the duration of the Tx.
Unfortunately there is no finer grained locking for CMP2 persistence
at this point but with the move to Java EE 5.0 and based on past
experience this is a good compromise and provides pretty good
performance.
On Nov 22, 2006, at 8:45 AM, Udovichenko, Nellya wrote:
It does not explicitly allow one to set isolation
level on each call though.
And what about the transaction isolation level setting for particular
EJB (in descriptor plan)?
Thanks,
Nellya.
-----Original Message-----
From: Matt Hogstrom [mailto:[EMAIL PROTECTED]
Sent: Monday, November 20, 2006 8:26 PM
To: [email protected]
Subject: Re: Updates to OEJB 2.2 and TranQL 1.4
Yes
Basically it allows one to specify select-for-update to delegate
locking to the db. It does not explicitly allow one to set isolation
level on each call though.
I'm modifying the Rar for db2 to allow the specification of a
default isolation level so one is not tied to RS for DB2.
On Nov 20, 2006, at 11:02 AM, Udovichenko, Nellya wrote:
Oh, by the way, doesn't this change address the transaction isolation
level
problem in TranQL/OpenEJB (GERONIMO-2128)?
Thanks,
Nellya Udovichenko.
-----Original Message-----
From: Matt Hogstrom [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 14, 2006 2:55 AM
To: [email protected]; [email protected]
Subject: Updates to OEJB 2.2 and TranQL 1.4
I have updated TranQL 1.4 and Open EJB 2.2 to support specification
of a Select-For-Update clause in the openejb-jar.xsd when deploying
CMP EJBs. I have published new SNAPSHOTs of both projects so in a
perfect world there should be no pain :)
I'll be stress testing DayTrader tonight to confirm that we can run
an EJB workload under stress. If no changes are made then the
current SQL syntax is generated and you'll notice no difference. If
you want you can add a <select-for-update>true</select-for-update>
element to the Entity element in your openejb-jar.
I'll post some results when I finish testing.
Cheers.
Matt Hogstrom
[EMAIL PROTECTED]
Matt Hogstrom
[EMAIL PROTECTED]
When the clouds are full they pour the rain out on the earth;
and whether a tree falls to the north, or it falls to the south,
wherever the tree falls, there is lies.
Matt Hogstrom
[EMAIL PROTECTED]
When the clouds are full they pour the rain out on the earth;
and whether a tree falls to the north, or it falls to the south,
wherever the tree falls, there is lies.
