Bugzilla – Full Text Bug Listing
| Summary: | Exception "Durable locking is not enabled." during save of changes | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Markus Surudo <ms> | ||||
| Component: | cdo.core | Assignee: | Caspar D. <caspar_d> | ||||
| Status: | CLOSED FIXED | QA Contact: | Eike Stepper <stepper> | ||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | ms, saulius.tvarijonas | ||||
| Version: | 4.1 | Flags: | stepper:
review+
|
||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Markus Surudo
The cause is in CDOTransactionImpl:
public void postCommit(CommitTransactionResult result)
{
if (isDirty())
{
...
}
else
{
// Removes locks even if no one touch the transaction
if (options().isAutoReleaseLocksEnabled())
{
unlockObjects(null, null);
}
}
}
The problem only occurs when attempting to commit an empty changeset, i.e. a not-dirty transaction. In that case possible explicit locks are released if auto-release-locks is enabled (the default).
Caspar, I think you know best how to determine whether there are explicit locks acquired at that time (bug 353691?). Can you please try to fix this bug?
I've already committed (but disabled) a test case: org.eclipse.emf.cdo.tests.offline.OfflineTest._testEmptyCommit()
(In reply to comment #1) > Caspar, I think you know best how to determine whether there are explicit locks > acquired at that time (bug 353691?). Can you please try to fix this bug? > > I've already committed (but disabled) a test case: > org.eclipse.emf.cdo.tests.offline.OfflineTest._testEmptyCommit() Explicit but non-durable locks aren't supported in a master-clone setup. So any call to #lock or #unlock would cause the same exception. I think the correct way of addressing this is to eliminate the explicit unlock call. Rather, we better just send the empty commit, which will trigger an *implicit* unlock. This solves the problem and simplifies the code to boot. Created attachment 207461 [details]
Patch v1 (Git patch)
Apply with 'git apply'.
> Apply with 'git apply'. That worked. I agree with your solution and approve the patch. Still it would be nice to not have the server contacted in case that the transaction is both not dirty and free of explicit locks. Isn't it possible to determine that (now that bug 353691 is resolved)? > I agree with your solution and approve the patch. Commit b2636bc4119b33bd1365c504659df0d15e472a62. > Still it would be nice to not have the server contacted in case that the > transaction is both not dirty and free of explicit locks. Isn't it possible to > determine that (now that bug 353691 is resolved)? Not easily. How do we find out whether the view holds any locks or not? Obviously, if we introduce a signal to get that info from the server, then we've defeated the purpose. But I can think of no other way. The bugzilla you refer to introduced a cache for lock states, but that cache just holds lockStates that happen to have been loaded. There's no telling whether it holds all the locks that the view owns -- some of them just may not have been loaded. Besides, even if you come up with a solution for the above, are you sure that it's a good idea? When I was debugging through the code with the patch applied, I noticed that a LOT of functionality (events etc.) now gets invoked that used to get skipped; and it doesn't make much sense to me that it was being skipped. It looks like functionality that should be invoked even if the commit is non-dirty. Okay, I agree ;-) Closing. |