> 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.
