As I asked in my previous email, please also set the jta log level to
FINE. Rerun the application and send the complete output, i.e., server
log from the first request till the last request.
Sahoo
Kenneth Clark wrote:
> The log files spat out this:
>
> [#|2007-10-30T10:47:35.079+0200|FINER|sun-appserver9.1|oracle.toplink.essentials.session.file:/usr/local/glassfish2/domains/domain1/applications/j2ee-modules/STT_AX_Services/-ax_ps
> 01.transaction|_ThreadID=52;_ThreadName=httpSSLWorkerThread-8081-2;ClassName=null;MethodName=null;_RequestID=b8559ca6-d2dc-4a62-b041-149a7034baf1;|begin unit of work commit|#]
>
> [#|2007-10-30T10:47:35.080+0200|FINER|sun-appserver9.1|oracle.toplink.essentials.session.file:/usr/local/glassfish2/domains/domain1/applications/j2ee-modules/STT_AX_Services/-ax_ps
> 01.transaction|_ThreadID=52;_ThreadName=httpSSLWorkerThread-8081-2;ClassName=null;MethodName=null;_RequestID=b8559ca6-d2dc-4a62-b041-149a7034baf1;|commit transaction|#]
>
> [#|2007-10-30T10:47:35.083+0200|FINER|sun-appserver9.1|oracle.toplink.essentials.session.file:/usr/local/glassfish2/domains/domain1/applications/j2ee-modules/STT_AX_Services/-ax_ps
> 01.transaction|_ThreadID=52;_ThreadName=httpSSLWorkerThread-8081-2;ClassName=null;MethodName=null;_RequestID=b8559ca6-d2dc-4a62-b041-149a7034baf1;|end unit of work commit|#]
>
> [#|2007-10-30T10:47:35.083+0200|FINER|sun-appserver9.1|oracle.toplink.essentials.session.file:/usr/local/glassfish2/domains/domain1/applications/j2ee-modules/STT_AX_Services/-ax_ps
> 01.transaction|_ThreadID=52;_ThreadName=httpSSLWorkerThread-8081-2;ClassName=null;MethodName=null;_RequestID=b8559ca6-d2dc-4a62-b041-149a7034baf1;|resume unit of work|#]
>
> Which leads me to believe the transaction was committed. Am I correct?
>
>
> ________________
> Thanks and regards
>
> Kenneth Clark
> Solutions Engineer
>
>
> Tel: 27 11 679 3075
> Mobile: 27 (0) 84 583 1348
> Email: kenneth.clark_at_skyetech.co.za
> Website: http://www.skyetech.co.za
>
>
> -----Original Message-----
> From: Sanjeeb.Sahoo_at_Sun.COM [mailto:Sanjeeb.Sahoo_at_Sun.COM] On Behalf Of Sahoo
> Sent: 30 October 2007 10:42
> To: users_at_glassfish.dev.java.net
> Subject: Re: Glassfish Oracle Mystery
>
> Kenneth Clark wrote:
>
>> That sql is consistent with that data structure and it is the only query being called at that time.
>>
>>
> Is it possible that there is some other query which is executed after
> that query?
> If that is not true, then possible reasons include:
> 1. JDBC driver is not functioning correctly.
> 2. Database backend is not functioning correctly.
> 3. The transaction is not getting committed.
>
> #2 can be verified by looking the database log file.
> #3 can be verified by setting jta logger level to FINE. You can use
> admin console or asadmin command to change this log level. I suggest you
> try this first before checking the database or the driver.
>
> Thanks,
> Sahoo
>
>
>> ________________
>> Thanks and regards
>>
>> Kenneth Clark
>> Solutions Engineer
>>
>>
>> Tel: 27 11 679 3075
>> Mobile: 27 (0) 84 583 1348
>> Email: kenneth.clark_at_skyetech.co.za
>> Website: http://www.skyetech.co.za
>>
>> -----Original Message-----
>> From: Sanjeeb.Sahoo_at_Sun.COM [mailto:Sanjeeb.Sahoo_at_Sun.COM] On Behalf Of Sahoo
>> Sent: 29 October 2007 14:15
>> To: users_at_glassfish.dev.java.net
>> Subject: Re: Glassfish Oracle Mystery
>>
>> You have to tell if the update query looks correct as per the data you
>> are trying to update. Secondly, is that the only query sent to the
>> database? If yes, how come the changes are lost?
>>
>> Thanks,
>> Sahoo
>>
>> Kenneth Clark wrote:
>>
>>
>>> Thanks for that, after I asked the question I recoiled in horror at my stupidity and upped the log level and received the following output:
>>>
>>> [#|2007-10-29T11:41:57.838+0200|FINE|sun-appserver9.1|oracle.toplink.essentials.session.file:/usr/local/glassfish2/domains/domain1/applications/j2ee-modules/STT_AX_Services/-ax_ps0
>>> 1.sql|_ThreadID=22;_ThreadName=httpSSLWorkerThread-8081-1;ClassName=null;MethodName=null;_RequestID=d7ba1f08-398c-405d-b078-43009ff35399;|UPDATE PRODUCT SET DESCRIPTION = ?, CODE =
>>> ? WHERE (ID = ?)
>>> bind => [Description1, Code1, AD0935F6-0089-08D4-0A1C-3411D785F931]|#]
>>>
>>> [#|2007-10-29T11:41:57.843+0200|FINER|sun-appserver9.1|oracle.toplink.essentials.session.file:/usr/local/glassfish2/domains/domain1/applications/j2ee-modules/STT_AX_Services/-ax_ps01.transaction|_ThreadID=22;_ThreadName=httpSSLWorkerThread-8081-1;ClassName=null;MethodName=null;_RequestID=d7ba1f08-398c-405d-b078-43009ff35399;|TX beforeCompletion callback, status=STATUS_ACTIVE|#]
>>>
>>> [#|2007-10-29T11:41:57.843+0200|FINER|sun-appserver9.1|oracle.toplink.essentials.session.file:/usr/local/glassfish2/domains/domain1/applications/j2ee-modules/STT_AX_Services/-ax_ps
>>> 01.transaction|_ThreadID=22;_ThreadName=httpSSLWorkerThread-8081-1;ClassName=null;MethodName=null;_RequestID=d7ba1f08-398c-405d-b078-43009ff35399;|begin unit of work commit|#]
>>>
>>> [#|2007-10-29T11:41:57.845+0200|FINER|sun-appserver9.1|oracle.toplink.essentials.session.file:/usr/local/glassfish2/domains/domain1/applications/j2ee-modules/STT_AX_Services/-ax_ps01.transaction|_ThreadID=22;_ThreadName=httpSSLWorkerThread-8081-1;ClassName=null;MethodName=null;_RequestID=d7ba1f08-398c-405d-b078-43009ff35399;|TX afterCompletion callback, status=COMMITTED|#]
>>>
>>> So it appears to have committed but when I refresh the rows in the database the changes are not there. Again, the persist mechanism is working, it is just the merge that is giving problems.
>>>
>>> ________________
>>> Thanks and regards
>>>
>>> Kenneth Clark
>>> Solutions Engineer
>>>
>>>
>>> Tel: 27 11 679 3075
>>> Mobile: 27 (0) 84 583 1348
>>> Email: kenneth.clark_at_skyetech.co.za
>>> Website: http://www.skyetech.co.za
>>>
>>>
>>> -----Original Message-----
>>> From: Sankara.Rao_at_Sun.COM [mailto:Sankara.Rao_at_Sun.COM]
>>> Sent: 29 October 2007 11:46
>>> To: users_at_glassfish.dev.java.net
>>> Subject: Re: Glassfish Oracle Mystery
>>>
>>> Kenneth Clark wrote:
>>>
>>>
>>>
>>>> Ok n00b time. How do I configure the persistence.xml to display the queries?
>>>>
>>>>
>>>>
>>>>
>>> From the FAQ link, Sahoo sent in his earlier mail:
>>> /Q. How do I configure the logging level for Toplink?/
>>>
>>> For both Java SE and EE, You can set the logging level for a persistence
>>> unit by using the following property:
>>>
>>> <property name="toplink.logging.level" value="%DESIRED_LOGGING_LEVEL"/>
>>>
>>> In GlassFish, you can set the global log level for all the persistence
>>> units using the admin GUI or asadmin CLI. The value specified in
>>> persistence.xml overrides the global log level. Please read
>>> https://glassfish.dev.java.net/javaee5/persistence/entity-persistence-support.html#Logging
>>> for more details.
>>>
>>> /Q. How can I see the sql generated by Toplink Essentials?/
>>>
>>> Set the logging level to *FINE* to see the sql generated by Toplink
>>> Essentials.
>>>
>>>
>>>
>>>
>>>> ________________
>>>> Thanks and regards
>>>>
>>>> Kenneth Clark
>>>> Solutions Engineer
>>>>
>>>>
>>>> Tel: 27 11 679 3075
>>>> Mobile: 27 (0) 84 583 1348
>>>> Email: kenneth.clark_at_skyetech.co.za
>>>> Website: http://www.skyetech.co.za
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Sanjeeb.Sahoo_at_Sun.COM [mailto:Sanjeeb.Sahoo_at_Sun.COM] On Behalf Of Sahoo
>>>> Sent: 29 October 2007 10:40
>>>> To: users_at_glassfish.dev.java.net
>>>> Subject: Re: Glassfish Oracle Mystery
>>>>
>>>> 1. Run your original code, i.e., *without* getTransaction().begin() and
>>>> commit. Since you are using an injected entity manager, you mst not use
>>>> getTransaction().begin() or commit().
>>>>
>>>> 2. See what SQL is being issued by TopLink Essential. You can configure
>>>> your persistence.xml [1], redeploy and rerun to see the SQL.
>>>>
>>>> Sahoo
>>>>
>>>> [1]
>>>> https://glassfish.dev.java.net/javaee5/persistence/persistence_faq.html#45
>>>>
>>>> Kenneth Clark wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> There is nothing in the log file other than “Cannot use an EntityTransaction while using JTA.” When I try using the em.getTransaction.
>>>>>
>>>>> I am not understanding what you mean by "what sql is being run" as I am using the entity manager to persist the data and update the data.
>>>>>
>>>>> The scenario is as follows. Frontend populates objected to be merged, is passed back to the webservice, the webservice calls em.merge(object) and then the frontend requests a list of those specific objects. The returned list reflects the changes but the database does not. Hence my conclusion that the transaction is not being committed.
>>>>>
>>>>> I noted this behavior on Postgres and resolved it by using em.getTransaction().begin() and commit()
>>>>>
>>>>> ________________
>>>>> Thanks and regards
>>>>>
>>>>> Kenneth Clark
>>>>> Solutions Engineer
>>>>>
>>>>>
>>>>> Tel: 27 11 679 3075
>>>>> Mobile: 27 (0) 84 583 1348
>>>>> Email: kenneth.clark_at_skyetech.co.za
>>>>> Website: http://www.skyetech.co.za
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Sanjeeb.Sahoo_at_Sun.COM [mailto:Sanjeeb.Sahoo_at_Sun.COM] On Behalf Of Sahoo
>>>>> Sent: 29 October 2007 08:51
>>>>> To: users_at_glassfish.dev.java.net
>>>>> Subject: Re: Glassfish Oracle Mystery
>>>>>
>>>>> With your *original* code, what SQL statements are executed when you run
>>>>> your program? That might give a clue.
>>>>> Also, are there any exceptions in the log file?
>>>>>
>>>>> Thanks,
>>>>> Sahoo
>>>>>
>>>>> Kenneth Clark wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Nope, still nothing.
>>>>>>
>>>>>> I removed the em.getTransaction and added the em.flush() below the em.merge() and it is not committing the transactions. It is mind boggling because the em.persist is working but the em.merge does not!?!
>>>>>>
>>>>>> Any further ideas?
>>>>>>
>>>>>> ________________
>>>>>> Thanks and regards
>>>>>>
>>>>>> Kenneth Clark
>>>>>> Solutions Engineer
>>>>>>
>>>>>>
>>>>>> Tel: 27 11 679 3075
>>>>>> Mobile: 27 (0) 84 583 1348
>>>>>> Email: kenneth.clark_at_skyetech.co.za
>>>>>> Website: http://www.skyetech.co.za
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: glassfish_at_javadesktop.org [mailto:glassfish_at_javadesktop.org]
>>>>>> Sent: 28 October 2007 04:41
>>>>>> To: users_at_glassfish.dev.java.net
>>>>>> Subject: Re: Glassfish Oracle Mystery
>>>>>>
>>>>>> em.getTransaction() is intended for Java SE environment. You shouldn't use em.getTransaction() in your session beans. Your session bean by default uses container managed transaction so each business method already executes in the context of a JTA transaction. If this method is invoked via its webservice endpoint, the container will wrap the method body with a transaction. Not sure why the tx is not committed. You may want to try add a em.flush() after merge, though it is not really needed.
>>>>>>
>>>>>> -cheng
>>>>>> [Message sent by forum member 'cf126330' (cf126330)]
>>>>>>
>>>>>> http://forums.java.net/jive/thread.jspa?messageID=242512
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>>
>>>>>> No virus found in this incoming message.
>>>>>> Checked by AVG Free Edition.
>>>>>> Version: 7.5.503 / Virus Database: 269.15.12/1097 - Release Date: 2007/10/28 13:58
>>>>>>
>>>>>>
>>>>>> No virus found in this outgoing message.
>>>>>> Checked by AVG Free Edition.
>>>>>> Version: 7.5.503 / Virus Database: 269.15.12/1097 - Release Date: 2007/10/28 13:58
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>
>>>>> No virus found in this incoming message.
>>>>> Checked by AVG Free Edition.
>>>>> Version: 7.5.503 / Virus Database: 269.15.12/1097 - Release Date: 2007/10/28 13:58
>>>>>
>>>>>
>>>>> No virus found in this outgoing message.
>>>>> Checked by AVG Free Edition.
>>>>> Version: 7.5.503 / Virus Database: 269.15.12/1097 - Release Date: 2007/10/28 13:58
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG Free Edition.
>>>> Version: 7.5.503 / Virus Database: 269.15.12/1097 - Release Date: 2007/10/28 13:58
>>>>
>>>>
>>>> No virus found in this outgoing message.
>>>> Checked by AVG Free Edition.
>>>> Version: 7.5.503 / Virus Database: 269.15.12/1097 - Release Date: 2007/10/28 13:58
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition.
>>> Version: 7.5.503 / Virus Database: 269.15.12/1097 - Release Date: 2007/10/28 13:58
>>>
>>>
>>> No virus found in this outgoing message.
>>> Checked by AVG Free Edition.
>>> Version: 7.5.503 / Virus Database: 269.15.12/1097 - Release Date: 2007/10/28 13:58
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.503 / Virus Database: 269.15.12/1097 - Release Date: 2007/10/28 13:58
>>
>>
>> No virus found in this outgoing message.
>> Checked by AVG Free Edition.
>> Version: 7.5.503 / Virus Database: 269.15.12/1097 - Release Date: 2007/10/28 13:58
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.15.12/1098 - Release Date: 2007/10/29 09:28
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.15.12/1098 - Release Date: 2007/10/29 09:28
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>