Bugzilla – Full Text Bug Listing
| Summary: | [DB] New DBException "A lock could not be obtained" on CDOUserTransaction.commit() | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Fabien Giquel <fabien.giquel> | ||||||
| Component: | cdo.db | Assignee: | Stefan Winkler <stefan> | ||||||
| Status: | CLOSED WORKSFORME | QA Contact: | Eike Stepper <stepper> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | stefan, stepper, vaisegid | ||||||
| Version: | 4.1 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 336097 | ||||||||
| Attachments: |
|
||||||||
I doubt that is your wrong usage of CDO API, although I don't know your exact usage. IMHO the stack trace indicates that something in Derby is wrong. We generally recommend to use H2 rather than Derby. Maybe a new Derby version would also help. You know we are bound to what Orbit offers here. Is the exception predictably reproducible? Maybe Stefan has more ideas... Well, usually it's not Derby who's wrong. The problem with these exceptions is typically that Derby uses the most restrictive locking methods, in particular when creating or altering tables or columns (DDL). Maybe it's an error in CDO (though, I don't know what could have changed between the milestones, as I have not been this active, lately :-( ). Anyways, I'd like to analyze the problem, but for this, I need a reproducible minimal test case or example (if possible, without references to external projects). Could you reduce the corresponding modisco test case in order to make it work with plain CDO? (In reply to comment #2) > Well, usually it's not Derby who's wrong. The problem with these exceptions is > typically that Derby uses the most restrictive locking methods, in particular > when creating or altering tables or columns (DDL). AbstractHorizontalClassMapping.createValueMappings() in the stack trace could indicate that. > Maybe it's an error in CDO (though, I don't know what could have changed > between the milestones, as I have not been this active, lately :-( ). We replaced the CDOIDMeta concept by external references. ExternalReferenceManager.lookupByID() is also in the stack trace. Hi Stefan and Eike, i come back here about this problem : the bug is reproductible. I wrote a minimal test case for easy issue production. Here is the process : - use an Eclipse 3.7M5 - install required components from MoDisco nighlty update site http://download.eclipse.org/modeling/mdt/modisco/updates/nightly/ : -- select all features from "MoDisco Infratructure" category -- select the two features "MoDisco CDO Java Discoverer feature" & "MoDisco Java feature" from category "MoDisco Java Feature" - import attached Junit test project in the workspace - run the CDOJUnitTest class. --> you should get the same error as described in attached stack trace". The CDO implemented EPackage involved is in the plugin org.eclipse.gmt.modisco.java.cdo Thanks in advance for your help. Created attachment 189589 [details]
A Junit Test for getting the issue
Thank you, Fabien. I'll have a look.. I know that Egidijus has been active in several bugzillas in this area... Fabien, Can you test with 7178 revision or later? I think your problem should be solved. We got very similar problem during adding new EPackage'as into server. Hi Egidijus, thanks for the suggestion, I did connect to the emf.cdo svn and checkout the last revision of org.Eclipse.net4j.db (7312 > 7178). Then i launch again the junit test, making sure the net4j.db project from workspace is encountered, and i got again the same error. Are there other components to check out ? May be i should update cdo with one of the use one of the integration update site ? > I did connect to the emf.cdo svn and checkout the last revision of
> org.Eclipse.net4j.db (7312 > 7178). Then i launch again the junit test, making
> sure the net4j.db project from workspace is encountered, and i got again the
> same error.
You should checkout whole CDO not only org.eclipse.net4j.db plugin. Target bug fixes for this problem are in 336932, 336688
Rather than checkout whole CDO, is there any receznt update site available ? I think about those ones : http://www.eclipse.org/cdo/downloads/updates.php The continous integration build job has a maximum delay of 3 hours: https://hudson.eclipse.org/hudson/job/emf-cdo-integration/lastSuccessfulBuild/artifact/result/site.p2 The issue has disappeared since using the M6 CDO update site. I mark the bug as resolved. Removing from release notes... |
Created attachment 188170 [details] stacktrace Our non-reg JUnit tests on MoDisco project encounters some regression with recent M5 cdo release (org.eclipse.emf.cdo_4.0.0.v20110201-0703) with message "A lock could not be obtained within the time requested". The DBexception occurs (see attached stacktrace) when calling CDOUserTransaction.commit() service. The root exception seems to be the java.sql.SQLException build from org.apache.derby.impl.services.locks.ConcurrentLockSet. Does anyone has an idea ? Could it it be a wrong use of CDO API ?