Folks, Thanks for all you help. This is very useful. Derby is a great database for prototyping, and I was bummed that it wasn't working.
I added the property and it worked like a charm. Regards, Robert Jackson Jeremy Bauer wrote: > > Robert, > > Concerned that this was a bug, I dug a little deeper and found that > the problem is the result of a database lock due to the default > isolation level on the data source. Most of your code runs in a > single transaction, TX1. The checking and savings rows are read from > the database with isolation level repeatable read. Then when > UpdateCheckingBalance is called with REQUIRES_NEW, a new transaction, > TX2 is created and JPA tries to update the CheckingAccount table, but > the row to update is locked in TX1. When I changed the > webSphereDefaultIsolationLevel property to read committed the > application worked fine since there was no lock on the initial read. > DB2 and Derby are set to repeatable read, while Oracle is set to read > committed on WebSphere - which explains why Oracle works out of the > box. > > In addition to modifying the webSphereDefaultIsolationLevel property, > you could also set the isolation level on a resource reference for the > data source or use the OpenJPA property: > > <property name="openjpa.jdbc.TransactionIsolation" > value="read-committed"/> > > Yet a third option is to specify access intent settings, documented > here: > http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tejb_accessintentjpa.html > > Best of luck with your future JPA work! > > -Jeremy > > On Thu, Oct 30, 2008 at 4:54 AM, rjack <[EMAIL PROTECTED]> wrote: >> >> Folks, >> >> Thanks for finding the issue. With this particular application, I was >> attempting to demonstrate features we need for product. Our product is >> not >> using JPA right now, but i hope in the future we will be able to use it. >> >> Regards, >> >> Robert Jackson >> >> Jeremy Bauer wrote: >>> >>> Hi Robert, >>> >>> Thanks for posting your ear file and the word doc. I was able to use >>> it to reproduce the problem with DB2 and Derby and as you've seen, >>> strangely, the application works fine with Oracle. The culprit is the >>> use of TransactionAttribute.REQUIRES_NEW on >>> BankAccountsBean.UpdateCheckingBalance(). If you comment out >>> @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) on that >>> method the EJB operations will complete successfully. This gets >>> around the issue, but may not provide the transactional behavior you >>> intend. >>> >>> I haven't yet determined how the application, server, and DB is >>> supposed to behave using the set of transaction attributes you've >>> defined for the application logic, but as we've seen, there's >>> definitely an issue. I'll post as I find out more. >>> >>> -Jeremy >>> >>> >>> >>> On Wed, Oct 29, 2008 at 10:17 PM, rjack <[EMAIL PROTECTED]> wrote: >>>> >>>> Folks, >>>> >>>> 1) The test connection works with all datasources. I did notice it >>>> wasn't >>>> connecting on all IP addresses. I fixed that, but it's still not >>>> working. >>>> >>>> 2) I couldn't get MS SQL Server to work either. I'm using SQL Server >>>> Express >>>> which might be part of the problem. It did work as Derby did on >>>> Weblogic. >>>> >>>> 3) I'm going to attach some pictures of the WebSphere setup. >>>> >>>> Robert Jackson >>>> >>>> >>>> Michael Dick wrote: >>>>> >>>>> Hi Robert, >>>>> >>>>> Quick question, does the test connection button on the WebSphere GUI >>>>> work >>>>> for the Derby and MS SQL datasources? >>>>> >>>>> If test connection works, then OpenJPA should have no trouble getting >>>>> a >>>>> connection.. >>>>> >>>>> --mike >>>>> >>>>> On Wed, Oct 29, 2008 at 2:29 PM, Kevin Sutter <[EMAIL PROTECTED]> >>>>> wrote: >>>>> >>>>>> RJack, >>>>>> From what you are telling me, things should be working... :-) >>>>>> >>>>>> It sounds like you are creating an appropriate j2c component >>>>>> authentication >>>>>> alias. I verified that this should be used even with a global jndi >>>>>> lookup >>>>>> of the datasource. Setting custom properties on the datasource is >>>>>> another >>>>>> alternative, but should not be required. >>>>>> >>>>>> Maybe a trace of the failure would help? Or, even to start with, the >>>>>> SystemOut.log that shows the error. >>>>>> >>>>>> Also, what did you do to get SQLServer to work? >>>>>> >>>>>> Thank you for your patience, >>>>>> Kevin >>>>>> >>>>>> On Wed, Oct 29, 2008 at 11:31 AM, rjack <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> > >>>>>> > Kevin, >>>>>> > >>>>>> > I'm attaching the EAR I'm using in WebSphere. I am defining a >>>>>> datasource >>>>>> > with that name, "JavaTranDerby". >>>>>> > >>>>>> > In both cases of Derby and Oracle, I"m creating a login/password >>>>>> using >>>>>> J2C >>>>>> > Authentication data and setting the login for XA Recovery and >>>>>> > authentication >>>>>> > for component management. I wonder if I need to set custom >>>>>> properties >>>>>> for >>>>>> > Derby. In networked mode it seems to want a userId and Password >>>>>> even >>>>>> if >>>>>> > they >>>>>> > are fake. >>>>>> > >>>>>> > I can access Derby on the WebSphere server remotely using >>>>>> DBvisualizer >>>>>> > with >>>>>> > no problem. I tried the jars that come with WAS 7 and also the 10.4 >>>>>> Derby >>>>>> > jars. >>>>>> > >>>>>> > Robert >>>>>> > >>>>>> > >>>>>> > http://n2.nabble.com/file/n1394204/Transaction.ear Transaction.ear >>>>>> > >>>>>> > Kevin Sutter wrote: >>>>>> > > >>>>>> > > RJack, >>>>>> > > According to your persistence.xml file, you are attempting to use >>>>>> a >>>>>> > > jta-data-source: >>>>>> > > >>>>>> > > - <#> <persistence-unit name="*TransactionEJBPU*" >>>>>> > > transaction-type="*JTA*" >>>>>> > >> >>>>>> > > <jta-data-source>JavaTranDerby</jta-data-source> >>>>>> > > </persistence-unit> >>>>>> > > >>>>>> > > This indicates that you need to have a DataSource configured at >>>>>> the >>>>>> jndi >>>>>> > > name of "JavaTranDerby". Do you? Normally, customers would >>>>>> preface >>>>>> the >>>>>> > > global Datasource jndi names with "jdbc/", but that's not a hard >>>>>> > > requirement. If you have configured this datasource in WebSphere >>>>>> with >>>>>> > > that >>>>>> > > jndi name, then OpenJPA should be able to find it. And, if you >>>>>> do >>>>>> have >>>>>> > it >>>>>> > > configured in WebSphere, then all of the login information should >>>>>> be >>>>>> > > configured on that datasource. If you use the <jta-data-source> >>>>>> element, >>>>>> > > then no additional datasource configuration properties will be >>>>>> used. >>>>>> > > >>>>>> > > If you do not plan to or want to configure a datasource in >>>>>> WebSphere >>>>>> for >>>>>> > > the >>>>>> > > jndi look, then you will need to configure datasource >>>>>> configuration >>>>>> > > properties in your persistence.xml file. I am very surprised >>>>>> that >>>>>> this >>>>>> > > same >>>>>> > > configuration worked just fine with WegLogic. Did you have the >>>>>> jndi >>>>>> name >>>>>> > > for the datasource configured in WebLogic? Or, did you have to >>>>>> provide >>>>>> > > some >>>>>> > > configuration parameters to get around the datasource access? >>>>>> > > >>>>>> > > Now, a few other observations. The TransactionEAR.jar is not a >>>>>> normal >>>>>> > > .ear >>>>>> > > file. It looks to be an Eclipse project (or possibly some other >>>>>> IDE). >>>>>> > > Correct? It only contains source files. And, it doesn't seem to >>>>>> follow >>>>>> > > normal .ear file formatting. For example, the META-INF directory >>>>>> is >>>>>> > > located >>>>>> > > in a src directory. This would not be a normal location to >>>>>> search >>>>>> for >>>>>> a >>>>>> > > persistence.xml file. >>>>>> > > >>>>>> > > Can you provide the actual .ear file that you are attempting to >>>>>> install >>>>>> > > and >>>>>> > > use? >>>>>> > > >>>>>> > > I also see the jpa.reveng.xml file which seems to indicate that >>>>>> maybe >>>>>> > this >>>>>> > > project started with Hibernate and you are now moving to OpenJPA? >>>>>> Is >>>>>> > that >>>>>> > > the case? Just curious since OpenJPA is always interested in >>>>>> learning >>>>>> > > about >>>>>> > > Hibernate migration lessons. >>>>>> > > >>>>>> > > And, finally, you mentioned that you got this to work with Oracle >>>>>> 10g. >>>>>> > > What >>>>>> > > did you do to get that configuration to work for you? >>>>>> > > >>>>>> > > More questions than answers at this point... >>>>>> > > >>>>>> > > Thanks, >>>>>> > > Kevin >>>>>> > > >>>>>> > > >>>>>> > > On Tue, Oct 28, 2008 at 2:08 PM, rjack <[EMAIL PROTECTED]> wrote: >>>>>> > > >>>>>> > >> >>>>>> > >> Kevin, >>>>>> > >> >>>>>> > >> Thanks for your interest. I would like to have this working >>>>>> because >>>>>> it >>>>>> > >> would >>>>>> > >> be a great way to deploy prototypes which I do often. >>>>>> > >> >>>>>> > >> The server I'm using is Running WebSphere 7 GA on Windows 2003 >>>>>> Server, >>>>>> > >> Service Pack 2. >>>>>> > >> >>>>>> > >> I'm using container managed transactions. I'm uploading the >>>>>> source >>>>>> that >>>>>> > >> is >>>>>> > >> working in Weblogic 10.3. >>>>>> > >> >>>>>> > >> I wonder if I need to add userId and password at connection >>>>>> properties. >>>>>> > >> Right now I have them added as a J2C logins. >>>>>> > >> >>>>>> > >> Robert >>>>>> > >> >>>>>> > >> >>>>>> http://n2.nabble.com/file/n1390062/TransactionEAR.jarTransactionEAR.jar >>>>>> > >> >>>>>> > >> Kevin Sutter wrote: >>>>>> > >> > >>>>>> > >> > RJack, >>>>>> > >> > Can you provide a bit more information on what your operating >>>>>> > >> environment >>>>>> > >> > is? Are you using application-managed persistence contexts? >>>>>> Or, >>>>>> > >> > container-managed? Are you using base WebSphere v6.1, v6.1 + >>>>>> EJB3 >>>>>> > >> Feature >>>>>> > >> > Pack, or v7? >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > You should not require any additional properties to get this >>>>>> running. >>>>>> > >> > Except maybe for some Connection-related properties. Since >>>>>> JPA >>>>>> is >>>>>> > >> > optimistic by default, you should not set the LockManager to >>>>>> > >> pessimistic >>>>>> > >> > -- >>>>>> > >> > unless your application requires this extension. >>>>>> > >> > >>>>>> > >> > Being both an OpenJPA and WebSphere advocate, I would be >>>>>> interested >>>>>> in >>>>>> > >> > understanding why you are having difficulties getting this >>>>>> combination >>>>>> > >> to >>>>>> > >> > run. It should not be this difficult. Thanks for your help >>>>>> in >>>>>> making >>>>>> > >> > these >>>>>> > >> > products better. >>>>>> > >> > >>>>>> > >> > Kevin >>>>>> > >> > >>>>>> > >> > On Tue, Oct 28, 2008 at 12:43 PM, rjack <[EMAIL PROTECTED]> >>>>>> wrote: >>>>>> > >> > >>>>>> > >> >> >>>>>> > >> >> Folks, >>>>>> > >> >> >>>>>> > >> >> I got it to work using Oracle 10g. >>>>>> > >> >> >>>>>> > >> >> Robert Jackson >>>>>> > >> >> >>>>>> > >> >> rjack wrote: >>>>>> > >> >> > >>>>>> > >> >> > Folks, >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > I've been trying to get JPA to work with WebSphere. I'm not >>>>>> having >>>>>> > >> any >>>>>> > >> >> > success. >>>>>> > >> >> > >>>>>> > >> >> > Derby - 5 minutes to get going in Weblogic >>>>>> > >> >> > MS SQL Server - 10 minutes to get going in Weblogic >>>>>> > >> >> > >>>>>> > >> >> > I spent 2 days trying to get either working in WebSphere >>>>>> with >>>>>> no >>>>>> > >> >> success. >>>>>> > >> >> > >>>>>> > >> >> > Openjpa keeps complaining about pessimsitic locking and >>>>>> other >>>>>> > stuff. >>>>>> > >> >> > >>>>>> > >> >> > I tried adding these lines to my persistence.xml file: >>>>>> > >> >> > >>>>>> > >> >> > <properties> >>>>>> > >> >> > <property name="openjpa.Optimistic" >>>>>> > >> >> value="false"/> >>>>>> > >> >> > <property name="openjpa.LockManager" >>>>>> > >> >> value="pessimistic"/> >>>>>> > >> >> > </properties> >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > I would love to get it working with a Derby Server. >>>>>> > >> >> > >>>>>> > >> >> > Any ideas... >>>>>> > >> >> > >>>>>> > >> >> > Robert Jackson >>>>>> > >> >> > >>>>>> > >> >> >>>>>> > >> >> -- >>>>>> > >> >> View this message in context: >>>>>> > >> >> >>>>>> http://n2.nabble.com/OpenJPA-on-WebSphere-tp1387725p1389637.html >>>>>> > >> >> Sent from the OpenJPA Users mailing list archive at >>>>>> Nabble.com. >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> > >>>>>> > >> > >>>>>> > >> >>>>>> > >> -- >>>>>> > >> View this message in context: >>>>>> > >> http://n2.nabble.com/OpenJPA-on-WebSphere-tp1387725p1390062.html >>>>>> > >> Sent from the OpenJPA Users mailing list archive at Nabble.com. >>>>>> > >> >>>>>> > >> >>>>>> > > >>>>>> > > >>>>>> > >>>>>> > -- >>>>>> > View this message in context: >>>>>> > http://n2.nabble.com/OpenJPA-on-WebSphere-tp1387725p1394204.html >>>>>> > Sent from the OpenJPA Users mailing list archive at Nabble.com. >>>>>> > >>>>>> > >>>>>> >>>>> >>>>> >>>> http://n2.nabble.com/file/n1396702/websphere_settings.doc >>>> websphere_settings.doc >>>> -- >>>> View this message in context: >>>> http://n2.nabble.com/OpenJPA-on-WebSphere-tp1387725p1396702.html >>>> Sent from the OpenJPA Users mailing list archive at Nabble.com. >>>> >>>> >>> >>> >> >> -- >> View this message in context: >> http://n2.nabble.com/OpenJPA-on-WebSphere-tp1387725p1397615.html >> Sent from the OpenJPA Users mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://n2.nabble.com/OpenJPA-on-WebSphere-tp1387725p1399387.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
