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