Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] questions while running JPA JUnit tests 
Hi Dies,
I think we need to try to isolate the sets of things that cause these "locked by another user" exceptions. It is certainly possible there are some tests where we could do some more clean-up - we rely quite a bit on Java garbage collection in our tests to close things.
It sounds like it is fairly easy to recreate the issue in EntityManagerJunitTestSuite.
Which line in testSequenceObjectsDefinition hangs? How about testSequenceObjectsDefinition? When we know that, we can take a look at what has happened previously in the tests suite to see what could be causing the issue.
There are some persistence unit properties for connection configuration (including connection pools) in this section of the doc that you could use to experiment. 

  You mention the following:

> On Symfoware, if you open a connection and create a table, you can't use
> that table from other connections until the connection with which the
> table was created is closed.
Is this just a "CREATE TABLE" issue or is it an issue with other statements like UPDATE and DELETE? What about SELECT? Does Symfoware tend to work when used with Connection Pools on application servers? 

-Tom

Dies Koper wrote:

Hi Tom,


2. For the connection issues, some comments/questions
- I wonder if some early test failures cause corruption of the connections. Do you see the connection problems as part of your first error, or is it something else?
If I run the FullRegressionTestSuite, it almost always hangs after it tried to drop sequence testSequenceObjectsDefinition. It failed in the deletion of this sequence because it was "locked by another user".
- Does your Symfoware database allow a limited number of connections and if so, what is the limit?
I think there is a limit on the client side (not sure what it's default is) and on the server side. On the server side I've increased it twice from 256 to 356 to 456 but it still hangs at the same spot. When it is hanging, I cannot connect to the database through the web-based admin console either, so the limit on the client side seems irrelevant.
Is there a way I can see how many connections are used at a certain time within EclipseLink? Some MBean, or a particular variable I can look at in the debugger?
And is there a way to run the tests with EclipseLink's connection pooling off? 
I've tried setting the following in ConnectionPool but saw no difference:

    public static final int MAX_CONNECTIONS = 1;
    public static final int MIN_CONNECTIONS = 0;
    public static final int INITIAL_CONNECTIONS = 0;
    public static final int WAIT_TIMEOUT = 10000; // 3 minutes.

Can they be specified in the test set somewhere in a single place?
- It sometimes helps to take the individual suites that are listed in FullRegressionSuite and run them individually to reduce the number of tests and see if the connectin problems still occurs. Are you running FullRegressionTestSuite as a whole, or are you running individual suites that are components of FullRegressionTestSuite? 

I have also tried running individual test suites.
EntityManagerJUnitTestSuite hangs in the same place as when I run FullRegressionTestSuite. The error messages before it complain about the temporary table being locked by another user (testSequenceObjectsDefinition). All logged SQLExceptions before this are expected errors (DROP statements that fail because I start with a clean DB, sequence's next_val failing because the sequence hasn't been created yet).
I have heard that Symfoware focussed on data integrity so it locks a lot. We have seen the following issue before:
On Symfoware, if you open a connection and create a table, you can't use that table from other connections until the connection with which the table was created is closed.
At least that was my understanding of it. So if I could ensure EclipseLink uses only one connection, it should stop complaining about other users using tables.. 

Thanks,
Dies


Tom Ware wrote:

Hi Dies,
I am hoping to get chanes for the supportsPrimaryKeyConstraint() and the majority of the SQL reserved word issues checked in fairly soon. There may be some SQL reserved word issues we have to deal with separately (mostly with SEQUENCE). I'll update the bug when I check-in with the current state.
Does Symfoware support outer join in the Where clause? We have support for writing SQL statements in an alternate way for database platforms that have that support. Have a look at the operatorOuterJoin() and shouldUseJDBCOuterJoinSyntax() and shouldPrintOuterJoinInWhereClause() methods in various database platforms. (e.g. OraclePlatform) 

-Tom

Dies Koper wrote:

Hi Tom,


   Why does it check supportsPrimaryKeyConstraint() and not
supportsUniqueKeyConstraint()?
It is possible, this is a legacy issue. (i.e. from before we had platform support for unique key constraints) Please file a bug. 

Done!
https://bugs.eclipse.org/bugs/show_bug.cgi?id=289403


2. Check-in:  bug 289019, bug 289020, bug 289021 and bug 289023
   You merged the patches into one and marked the bugs as fixed. Have
you committed the patch? I couldn't find it in trunk.
I am not sure what happened to my check-in. The changes should be there now. 

Thanks!


3. INNER JOIN
   Symfoware does not support (INNER) JOIN syntax.
"JOIN" is used in SQLSelectStatement twice, at least one of which is 
used when using a self-referencing many to many relationship and
performing a (JPQL) LEFT OUTER JOIN query. I can prevent the syntax
error by replacing the inner join by a left outer join for Symfoware,
but I'm worried that might select too many rows. I suppose a better
solution is to compare join keys in the where clause. What do you think? Do you happen to know an easy way to do that (using existing code)? If 
not, never mind, I'll do some more research myself.
Could you please give an example of a statement that gives you an issue, what the resulting SQL is, and what part of it is not supported by Symfoware? 

Query query = em.createQuery("SELECT o from Person o LEFT OUTER JOIN
o.persons AS p");

gives:
SELECT t0.ID, t0.NAME, t1.ID, t1.NAME FROM {oj PERSON t0 LEFT OUTER JOIN 
(PERSON_PERSON t2 JOIN PERSON t1 ON (t1.ID = t2.persons_ID)) ON
(t2.Person_ID = t0.ID)}

Symfoware complains about "JOIN", saying that the join type is not
specified. Legal values are LEFT/RIGHT (OUTER).

So I suppose I should change it to generate something like:
SELECT t0.ID, t0.NAME, t1.ID, t1.NAME FROM {oj PERSON t0 LEFT OUTER JOIN 
(SELECT PERSON_PERSON t2, PERSON t1 WHERE t1.ID = t2.persons_ID) ON
(t2.Person_ID = t0.ID)}


4. Patches.
Start by attaching the single patch to the Symfoware platform bug and describing the issues. If any of the changes are large enough to merit their own bug, we can add the bug later. 

Done!
https://bugs.eclipse.org/bugs/show_bug.cgi?id=288715


 From your previous email:

1. --

LANGUAGE, VALUE, DOMAIN, SEQUENCE

- I am still hoping to find the time to deal with these issues.
I have enclosed most if not all occurrences in double-quotes in the patch I attached to the bug for SymfowarePlatform. That worked for me with Symfoware, and I have also confirmed with Derby that none of my changes caused new failures on Derby. 

56% of 1270 tests (I temporarily disabled some) are currently passing.
I will document some of the limitations in this platform I found on the Wiki tomorrow.
The biggest issue I still have is that I get errors saying that the resource (table, etc.) is locked by another user, or sometimes it even hangs on getConnection. I checked with the JDBC driver's trace info and found the number of calls to getConnection to be much higher than the number of calls to close(). I assume that this could be related. I don't know whether connections were not closed because cleanup processing did not complete for failing JUnit tests, or something else is going on, but if you have any suggestions I'm all ears. What I'll try first is to disable ElipseLink connection pooling and see how that affects it.
I also hope you can find some time to review the patches I attached to the bug. You might see something obviously wrong or missing that can help boost the passing rate when fixed. 

Thanks!
Dies


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

Back to the top