openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <kwsut...@gmail.com>
Subject Re: OpenJpa, and DB2 shared lock
Date Wed, 22 Apr 2009 17:18:52 GMT
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 <cthella@yahoo.com> 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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message