Community
Participate
Working Groups
Build Identifier: M20110909-1335 - CDO Master/Clone setup - MySQL database - newest CDO Build (updated 2011-11-23) After importing a resource into CDO it can be edited and changes can be saved to the repository. It doesn't matter, if the server is restarted or not, it is always possible to save. If a second resource is imported it is possible to save this resouce but from this point on all tries to save changes to the repository (in all files of the respository, i.e. the first (in the beginning working) file and all other files) produce a "Durable locking is not enabled." exception and a rollback-dialog. Even though this exception occurs the dialog choice has no effect on the save operation. The changes are always stored nethertheless. This was no problem prior to V4.1 Reproducible: Always Steps to Reproduce: 1. Import resource to repository 2. Edit resource in repository and save the changes (should be no problem) 3. Import second file to repository 4. A try to save this change should create above mentioned exception
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.
