Hi Tom, Gordon,
I am trying to investigate this issue. I observed that current toplink
code uses non-tx connection to execute the query. To experiment I
changed toplink code to use the transactional connection
(maindataSource) instead of non-tx connection (readDatasource) to
execute the query and the hang goes away.
Looks like the cause for this issue is one of following.
(1). Toplink was changed to use non-tx connection between June 29th
(date of merge that corresponds to build 8) to Aug 30 (date of merge
that corresponds to build 9). Do you think it is the case? Or any other
changes that you might suspect?
(2). The non-tx connection pool impl of glassfish has changed and is not
properly delisting the connection.
Hi Binod,
Stepping throu gh toplink's code, I observed that toplink does properly
close the non-tx connection after executing the query. Do you think
anything has changed in the connection pool impl in this area between
UR1 build 8 and 9 that correposnds to (2) above ? Any other hints you
can think of to debug this issue?
Thanks,
Mitesh
sdo_at_dev.java.net wrote:
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=1059
> Issue #|1059
> Summary|native queries not being committed
> Component|glassfish
> Version|9.0peur1
> Platform|All
> OS/Version|All
> URL|
> Status|UNCONFIRMED
> Status whiteboard|
> Keywords|
> Resolution|
> Issue type|DEFECT
> Priority|P3
> Subcomponent|entity-persistence
> Assigned to|mvatkina
> Reported by|sdo
>
>
>
>
>
>
> ------- Additional comments from sdo_at_dev.java.net Thu Aug 31 18:40:04 +0000 2006 -------
> Starting with nightly builds for 9.0_01 this week, native queries are no longer
> being committed. I don't know the exactly nightly it was introduce, but
> somewhere between promoted build 8 and the August 30 nightly build.
>
> See the attachment for the test case. Essentially, we have this code (executed
> within a stateless session bean with default transaction semantics):
>
> Query q = em.createNativeQuery("select object(c) ... for update");
> Object o = q.getSingleResult();
>
> The first time this executes, the row lock is placed on the database, and the
> session bean executes -- this should end the transaction and commit the database
> work. However, that doesn't happen, and hence a second call to the same code
> will hang because it can't access that row in the database.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: issues-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: issues-help_at_glassfish.dev.java.net
>
>