Hello Mitesh,
I think it would be very difficult to track down the test author, as well the chance this person remembers what they were testing is quite slim. I have taken a closer look at the test case and I think it is just a typo (that no longer works with our updates).
Changing the "results = (List)((EntityManagerImpl)createEntityManager()).getActiveSession().executeQuery(query);" to call getServerSession() instead of getActiveSession() will continue to test that refreshing is working which seems to be what the test is intending.
Changing the test as you proposed would have us checking that the objects were read within this transaction instead of using the shared values which is not what the test appears to have intended.
--Gordon
-----Original Message-----
From: Mitesh.Meswani_at_Sun.COM [mailto:Mitesh.Meswani_at_Sun.COM]On Behalf Of Mitesh Meswani
Sent: Tuesday, September 05, 2006 1:01 PM
To: persistence_at_glassfish.dev.java.net
Subject: Re: [Issue 1059] New - native queries not being committed
Hi Gordon, Tom,
I am proposing following change to the test. Can you verify with the test author whether it is consistent with intent of the test.
diff -r1.9 SQLResultSetMappingTestSuite.java
90c90,91
< assertFalse("Object was not refreshed", buyer.getDescription().equals("To A new changed description"));
---
> Buyer buyerRetrieved = (Buyer)results.get(0);
> assertFalse("Object was not refreshed", buyerRetrieved.getDescription().equals("To A new changed description"));
Thanks,
Mitesh
Gordon Yorke wrote:
Hello Mitesh,
I am not sure what this test is attempting to test but it will have to change. I think the second check that is verfying no "refresh" should be removed.
--Gordon
-----Original Message-----
From: Mitesh.Meswani_at_Sun.COM [mailto:Mitesh.Meswani_at_Sun.COM]On Behalf Of
Mitesh Meswani
Sent: Friday, September 01, 2006 9:46 PM
To: Gordon Yorke
Cc: persistence_at_glassfish.dev.java.net
Subject: Re: [Issue 1059] New - native queries not being committed
Removing Binod from the spam...
Hi Gordon,
While running entity-persistence-test with these changes,
SQLResultSetMappingTestSuite#testInheritanceNoDiscriminatorColumn
failed. The test is as follows
public void testInheritanceNoDiscriminatorColumn() throws Exception {
SQLResultSetMapping resultSetMapping = new
SQLResultSetMapping("testInheritanceNoDiscriminatorColumn");
EntityResult entityResult = new EntityResult(Buyer.class);
resultSetMapping.addResult(entityResult);
entityResult.setDiscriminatorColumn("DTYPE_DESCRIM");
SQLCall call = new SQLCall("SELECT t0.BUYER_ID, t0.DTYPE AS
DTYPE_DESCRIM, t0.BUYER_NAME, t0.DESCRIP, t0.VERSION, t1.PURCHASES FROM
CMP3_BUYER t0, CMP3_PBUYER t1 WHERE t1.BUYER_ID = t0.BUYER_ID");
ResultSetMappingQuery query = new ResultSetMappingQuery(call);
query.setSQLResultSetMapping(resultSetMapping);
query.setShouldRefreshIdentityMapResult(true);
EntityManager em = createEntityManager();
em.getTransaction().begin();
try{
List results =
(List)((EntityManagerImpl)em).getServerSession().executeQuery(query);
assertNotNull("No result returned", results);
Buyer buyer = (Buyer)results.get(0);
buyer.setDescription("To A new changed description");
results =
(List)((EntityManagerImpl)createEntityManager()).getActiveSession().executeQuery(query);
<-----(1)
assertNotNull("No result returned", results);
*assertFalse("Object was not refreshed",
buyer.getDescription().equals("To A new changed description")); <-----
This assert fails*
}finally{
if (em.getTransaction().isActive()){
em.getTransaction().rollback();
}
}
}
We are getting a copy of the buyer object when we execute (1). I think
the test needs to change to accommodate the new semantics. What do you
think?
Thanks,
Mitesh
Gordon Yorke wrote:
Mitesh,
This looks good. Alternately you could simply call unitOfWork.beginEarlyTransaction() instead of the other 2 calls but it really makes no difference.
--Gordon
-----Original Message-----
From: Mitesh.Meswani_at_Sun.COM [mailto:Mitesh.Meswani_at_Sun.COM]On Behalf Of
Mitesh Meswani
Sent: Friday, September 01, 2006 4:23 PM
To: persistence_at_glassfish.dev.java.net
Cc: Binod P G; Gordon Yorke
Subject: Re: [Issue 1059] New - native queries not being committed
Hi Gordon,
Seems that the persistence alias is very slow today. I sent out a bit
different proposal few mins ago. But I think the proposal below makes
more sense. Attached are proposed changes to ResultSetMappingQuery to
implement the first part. Please review. We can implement the hint to
execute it in outside transaction later on.
Thanks,
Mitesh
Gordon Yorke wrote:
Marina,
Given that Native Queries are generally going to be used for special cases having them part of the transaction is probably best although it will sacrifice efficiency for users who are doing simple selects. We should not rollback the changes though (unless you are talking about the UR1 branch?) but for now should have all Native Queries "begin an early transaction" in the UnitOfWork as the ModifyAllQuery does. In the future we can add a hint to allow users to have native queries that can read outside of the transaction.
--Gordon
-----Original Message-----
From: Marina.Vatkina_at_Sun.COM [mailto:Marina.Vatkina_at_Sun.COM]On Behalf Of
Marina Vatkina
Sent: Friday, September 01, 2006 3:01 PM
To: persistence_at_glassfish.dev.java.net
Cc: Binod P G
Subject: Re: [Issue 1059] New - native queries not being committed
Gordon,
As the changes to use non-tx connections broke existing functionality,
we can't require users to add hints to get it back. It's possible
though to add hints to request new functionality.
As this bug is a show-stopper for UR1 release, can we rollback the
original changes?
thanks,
-marina
Gordon Yorke wrote:
Having a query use the transactional connection in TopLink is not as simple as it seems and caries with it some side effects on subsequent queries. I think we should have an option to force the query into the transaction that can be initiated by the user and we should attempt to detect pessimistic lock clauses.
--Gordon
-----Original Message-----
From: Marina.Vatkina_at_Sun.COM [mailto:Marina.Vatkina_at_Sun.COM]On Behalf Of
Marina Vatkina
Sent: Friday, September 01, 2006 1:37 PM
To: persistence_at_glassfish.dev.java.net
Cc: Binod P G
Subject: Re: [Issue 1059] New - native queries not being committed
Hi Mitesh,
I don't think that the answer is in the connection pool code. Non-tx connections
are not suitable for select ... for update, as such selects must be transactional.
Gordon,
Unless there is a complete parser in place that can understand what exactly a
native query is doing, I would think that native queries should be excluded
from non-tx connections optimizations.
thanks,
-marina
Mitesh Meswani wrote:
Gordon Yorke wrote:
Hello Mitesh,
In July (around the 20th) code was changed where if the SELECT was executed before a flush() or bulk update in the transaction then it would use the non-tx connection. (Select for update was not considered).
Is it possible that the connection pool was giving us the tx connection anyway?
We will have to wait for Binod's reply. But, looking at the fisheye logs
it does not seem that there was any change in the jdbcra module either
in trunk <
http://fisheye5.cenqua.com/changelog/glassfish/jdbcra> or in
the branch
<
http://fisheye5.cenqua.com/changelog/%7Ebr=SJSAS90_FCS_BRANCH/glassfish/jdbcra>
post Marrch 2006 so most probably the code change above should be the
root cause
A bug should be entered for the custom SQL SELECT FOR UPDATE case.
Issue 1059 corresponds to this issue. Any hints on how it can be resolved?
Thanks,
Mitesh
--Gordon
-----Original Message-----
From: Mitesh.Meswani_at_Sun.COM [mailto:Mitesh.Meswani_at_Sun.COM]On Behalf Of
Mitesh Meswani
Sent: Friday, September 01, 2006 3:10 AM
To: persistence
Cc: Binod P G
Subject: Re: [Issue 1059] New - native queries not being committed
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