Hi Chandra, On Wed, Apr 22, 2009 at 1:31 PM, Chandra Sarath <[email protected]> wrote:
> > Hi Kevin, > > Thank you! I'm answering the questions here.. > > 1. So Maven gets the 1.2.0 version and bundle all referenced jars in War > file and when we deploy we select to load classes in Application first than > Websphere6.1 classes that way it will use JPA1.2.0. only. I heard from my > lead that we install Websphere 6.1 with EJB 3 feature pack.. Sounds like you are on top of things. :-) Thanks. > > > 2. Yes. I'll turn on trace. But it will only trace out at JPA level > right? should I set TRACE for all parameters below? > > <prop > key="openjpa.Log">DefaultLevel=ERROR, Runtime=ERROR, Tool=ERROR, > SQL=ERROR </prop> Good point. I was only concerned with OpenJPA tracing. If the problem is elsewhere in the stack, then we're not going to know that we're being called. If you set DefaultLevel=TRACE, then if nothing else is set then every OpenJPA component will run with TRACE. Good luck, Kevin > > > Thanks, > Chandra > > > > Kevin Sutter wrote: > > > > Hi Chandra, > > The Trace will probably help with the diagnosis. I also have a few > > comments > > inline below... > > > > Thanks, > > Kevin > > > > On Wed, Apr 22, 2009 at 11:14 AM, Chandra Sarath <[email protected]> > > wrote: > > > >> > >> Hi Kevin, > >> > >> Thank you very much Kevin for your reply. Here are the answers (in > Italic > >> bold) to your questions.. > >> > >> Chandra > >> > >> > >> > >> Kevin Sutter wrote: > >> > > >> > Hi Chandra, > >> > I don't have an answer for you yet, just more questions at this > >> point... > >> > :-) > >> > > >> > o What version of OpenJPA are you running with? > >> > > >> > We are using version 1.2.0. What is recommended version? please let me > >> > know. > > > > > > The 1.2.x branch of OpenJPA is the one used with WebSphere v7. That > > branch > > would be my recommended version at this point. > > > > > >> > >> > > >> > o When you mention WAS v6.1, is this with or without the EJB3 Feature > >> > Pack? > >> > > >> > Yes we are. > > > > > > :-) This wasn't a yes or no question. I wanted to know whether you are > > running with the EJB3 FeP or not. > > > > If you are running with the EJB3 FeP, then the shipped version of OpenJPA > > is > > the 1.0.x branch of OpenJPA. But, above you mentioned that you are > > running > > with 1.2.x of OpenJPA. Did you install and configure OpenJPA 1.2.x as a > > shared library to override the version shipped with the EJB3 FeP? Or, > > maybe > > you are not running with the EJB3 FeP and you are running with base WAS > > v6.1? > > > > > >> > >> > > >> > o The update scenario... I'm assuming you are doing a find() > >> operation > >> > on > >> > an existing record. Are you doing this within an EntityTransaction? > >> I'm > >> > asking since if you are doing your update on this object while it is > >> > managed > >> > (part of the current persistence context), then there is no need to do > >> a > >> > merge() operation. The merge() is for bringing detached entities into > >> a > >> > persistence context (managed state). Just a clarification, I don't > >> think > >> > this is causing the problem. > >> > > >> > No. We are not doing find() before merge(). Since out parent and child > >> > objects are huge (100s of columns), we just set all fields sent by > >> client > >> > in Entity class and do a entityManager.merge(Object parent). > > > > > > Thanks for the clarification. > > > > > >> > >> > > >> > > >> > o Are you setting any other openjpa.* properties? Or, are you > running > >> > with > >> > the default runtime options? For example, optimistic locking is the > >> > default > >> > JPA mechanism, but OpenJPA also provides a pessimistic lock manager. > >> Any > >> > additional information on your environment? > >> > > >> > No we are not setting any extra properties other than these below. We > >> set > >> > these properties in Spring config file. > >> > > >> > ${db.schema} > >> > DefaultLevel=ERROR, > >> Runtime=ERROR, > >> Tool=ERROR, SQL=ERROR > >> > true > >> > SCHEMA_NAME > >> > dynamic > >> > ${db.dictonary} > >> > > >> > for the same lock mechanism (default one) its comes out after the time > >> out > >> > for inserts > >> > but not with the updates on same table. Our dba can clearly see the > >> same > >> > update request > >> > coming in to DB2 for every timeout seconds. > >> > > >> > > >> > o Off the top of my head, I am not aware of any retry logic within > the > >> > OpenJPA code. If a transaction fails, I'm pretty sure that we just > >> pass > >> > that back to the app and let them deal with it. Have you verified > that > >> > your > >> > app isn't accidentally retrying upon failure? (Have to ask.) > >> > > >> > I'm sure App is not doing it unless Websphere (datasource/non xa > >> driver) > >> > is doing which I think it will not.. > > > > > > Like I said, I had to ask. Clearly, somebody is doing the retry's. > Maybe > > it's Spring? Hopefully, the trace will help us figure out the culprit. > > > > > >> > >> > > >> > > >> > o Do you have more information on the exceptions received and any > >> related > >> > call stacks? If not, the next step might be to turn on Trace and see > >> what > >> > processing is happening. > >> > > >> > For inserts its just comes out and we can see the service failing.. > But > >> > for updates it didn't happen. Turning trace on is our next step if we > >> do > >> > not have much info. We don't have a local Websphere installed. Our > >> > development servers are used by multiple systems. > > > > > > It looks like you have OpenJPA configuration available via your Spring > > configuration. You should be able to modify your Spring configuration > > (from > > above) and change this logging option to TRACE: > > > >> ${db.schema} > >> DefaultLevel=TRACE > >> true > >> SCHEMA_NAME > >> dynamic > >> ${db.dictonary} > > > > Hope this helps, > > Kevin > > > > > >> > > >> > > >> > > >> > Good luck! > >> > Kevin > >> > > >> > On Wed, Apr 22, 2009 at 4:22 AM, Chandra Sarath wrote: > >> > > >> >> > >> >> Hi, > >> >> > >> >> We use OpenJpa, DB2 and Websphere 6.1. We have created a Datasource > in > >> >> Websphere console that connects DB2 using a non-xa driver. > >> >> > >> >> We were testing our application about how it rolls back the data when > >> >> there > >> >> is a shared lock in a table. we have following scenarios. We have > also > >> >> set > >> >> a > >> >> Timeout of 30 seconds in Datasource/connection properties. > >> >> > >> >> 1. Insert a record in a read only (Shared lock). > >> >> 2. Update a record in read only table (Shared lock). > >> >> > >> >> For Scenario 1, after 30 seconds application times out and gives us > >> >> proper > >> >> error. But for scenario 2, it goes in infinite > >> >> loop and tries to update Database for every 30 secs, and it never > >> stops > >> >> trying to. > >> >> > >> >> Is there any extra property that we need to set in Jpa level or > >> >> Datasource > >> >> level so application can timeout after 30 seconds? > >> >> > >> >> we use entityManager.persist() for inserts and entityManager.merge() > >> for > >> >> updates. Can someone help us on this? > >> >> > >> >> Thank you! > >> >> Chandra > >> >> -- > >> >> View this message in context: > >> >> > >> > http://n2.nabble.com/OpenJpa%2C-and-DB2-shared-lock-tp2675084p2675084.html > >> >> Sent from the OpenJPA Users mailing list archive at Nabble.com. > >> >> > >> >> > >> > > >> > > >> > >> -- > >> View this message in context: > >> > http://n2.nabble.com/OpenJpa%2C-and-DB2-shared-lock-tp2675084p2677165.html > >> Sent from the OpenJPA Users mailing list archive at Nabble.com. > >> > > > > > > -- > View this message in context: > http://n2.nabble.com/OpenJpa%2C-and-DB2-shared-lock-tp2675084p2677930.html > Sent from the OpenJPA Users mailing list archive at Nabble.com. > >
