Thanks Pinaki!
We are planning to turn on trace on development server tomorrow and see the
results. we will check out the JDBCListeners if we don't get much info..
Chandra
Pinaki Poddar wrote:
>
> Hi,
> Slightly off the main line:
>
>> 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.
>
> An application can sniff/record the SQL statements OpenJPA is issuing
> (see JDBCListeners) -- in case you have difficulty accessing the database
> logs and/or OpenJPA runtime traces.
>
>> 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).
>
> An application can control which fields are sent to the client
> selectively (see FetchPlan). May be quite useful from performance
> standpoint in this scenario provided the client is not interested in 100s
> of columns.
>
>
> Chandra Sarath 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.
>>>
>>> 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.
>>>
>>> <prop
>>> key="openjpa.jdbc.SynchronizeMappings">${db.schema}</prop>
>>> <prop
>>> key="openjpa.Log">DefaultLevel=ERROR, Runtime=ERROR,
>>> Tool=ERROR, SQL=ERROR </prop>
>>> <prop key="show_sql">true</prop>
>>> <prop
>>> key="openjpa.jdbc.Schemas">SCHEMA_NAME</prop>
>>> <prop
>>> key="openjpa.jdbc.SchemaFactory">dynamic</prop>
>>> <prop
>>> key="openjpa.jdbc.DBDictionary">${db.dictonary}</prop>
>>>
>>> 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 <[email protected]>
>>> 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-tp2675084p2679826.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
