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.
>
> o When you mention WAS v6.1, is this with or without the EJB3 Feature
> Pack?
>
> Yes we are.
>
> 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).
>
>
> 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..
>
>
> 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.
>
>
>
> 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.