I don't know. I will guess that in 5.4 the initialization of the
default shared editing context has been postponed until after the
Application constructor completes. Does that code below work if you
do that fetch somewhere else in your code?
Chuck
On Jan 2, 2008, at 10:37 AM, Ralf Schuchardt wrote:
Hello,
are there any known fundamental changes (or bugs) in the handling
of SharedEditingContexts in WO 5.4?
I have an application that has worked flawlessly with
SharedEditingContexts enabled in WO 5.3, but in 5.4 I get a strange
locking error when fetching objects.
I have this simple (test) code in Application():
EOEditingContext ec = new EOEditingContext();
ec.lock();
try {
EOFetchSpecification fetch = new EOFetchSpecification
("Kumulativdaten", null, null);
NSArray ks = ec.objectsWithFetchSpecification(fetch);
}
finally {
ec.unlock();
ec.dispose();
}
The entity "Kumulativdaten" has relationships to shared objects
(entities with "share all objects" set). I don't have any explicit
calls to EOEditingContext.sharedEditingContext or
EOSharedEditingContext.defaultSharedEditingContext.
The code runs fine with WO 5.3 and fetches the objects, but with
5.4 I get this error:
[2008-1-2 17:32:50 CET] <main> java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantReadWriteLock
$Sync.tryRelease(ReentrantReadWriteLock.java:259)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release
(AbstractQueuedSynchronizer.java:1137)
at java.util.concurrent.locks.ReentrantReadWriteLock
$WriteLock.unlock(ReentrantReadWriteLock.java:821)
at com.webobjects.eocontrol.EOSharedEditingContext.unlock
(EOSharedEditingContext.java:787)
at com.webobjects.eocontrol.EOEditingContext.unlockObjectStore
(EOEditingContext.java:4670)
at
com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecificatio
n(EOEditingContext.java:4057)
at
com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecificatio
n(EOEditingContext.java:4428)
at com.jip.bluter.Application.<init>(Application.java:71)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303)
at com.webobjects.appserver.WOApplication.main(WOApplication.java:
546)
at com.jip.bluter.Application.main(Application.java:45)
Somehow the shared EditingContext is not properly initialized or
locked, because the exception seems to indicate a missing lock.
I can prevent the error by a simple call to
EOSharedEditingContext.defaultSharedEditingContext() prior to
creating my EditingContext.
Is it really necessary to manually instantiate the
SharedEditingContext or could this be a bug in WO 5.4?
Thanks,
Ralf Schuchardt
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/chill%
40global-village.net
This email sent to [EMAIL PROTECTED]
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
