Re: EOEditingContexts with same Object store, different threads
Re: EOEditingContexts with same Object store, different threads
- Subject: Re: EOEditingContexts with same Object store, different threads
- From: Chuck Hill <email@hidden>
- Date: Sat, 4 Oct 2008 21:52:56 -0700
On Oct 4, 2008, at 9:08 PM, Jeff Schmitz wrote:
Yes, pool is an EO. And yes, adding an unlock/lock sequence as
shown below seems to have fixed the problem (thanks!)
public class PoolSync {
public synchronized boolean checkAndLock(Pool pool, String
threadName, EOEditingContext ec) {
System.out.println("checkAndLock called by " + threadName + "for
pool " + pool.name());
ec.unlock();
ec.lock();
if (!(pool.calculating())) {
pool.calculating(true);
ec.saveChanges();
System.out.println("setCalculating true " + threadName + " for
pool " + pool.name());
return true;
} else {
System.out.println("checkAndLock returning false " + threadName +
"for pool " + pool.name());
return false;
}
}
}
Now however, later in the processing I'm getting the exceptions
shown below for two of the threads. Can I assume this means I have
some unbalanced lock/unlock pairs that I need to find?
Exception in thread "Thread 2" java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock
$Sync.tryRelease(ReentrantLock.java:125)
at
java
.util
.concurrent
.locks
.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:
1137)
at
java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:
431)
at
com
.webobjects.eocontrol.EOEditingContext.unlock(EOEditingContext.java:
4635)
at er.extensions.ERXEC.unlock(ERXEC.java:455)
at com.netbracketsfw.core.FileIO64.calcCanIWins64(FileIO64.java:1034)
at com.netbracketsfw.core.FileIO64$1.run(FileIO64.java:1465)
Exception in thread "Thread 1" java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock
$Sync.tryRelease(ReentrantLock.java:125)
at
java
.util
.concurrent
.locks
.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:
1137)
at
java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:
431)
at
com
.webobjects.eocontrol.EOEditingContext.unlock(EOEditingContext.java:
4635)
at er.extensions.ERXEC.unlock(ERXEC.java:455)
at com.netbracketsfw.core.FileIO64.calcCanIWins64(FileIO64.java:1034)
at com.netbracketsfw.core.FileIO64$1.run(FileIO64.java:1465)
That looks like you are trying to unlock the EC from a different
thread than the one that locked it.
Chuck
On Oct 4, 2008, at 10:49 PM, Chuck Hill wrote:
On Oct 4, 2008, at 8:40 PM, Jeff Schmitz wrote:
Hello,
I'm trying to run three threads that perform long calculations
on data within the object space. Each thread needs to check EO
states set by the other threads at certain intervals to make sure
that it isn't working on the same calculations as other threads.
When checking these states, each thread goes through a common sync
point object of class PoolSync that has syncronized methods.
public class PoolSync {
public synchronized boolean checkAndLock(Pool pool, String
threadName, EOEditingContext ec) {
System.out.println("checkAndLock called by " + threadName + "for
pool " + pool.name());
if (!(pool.calculating())) {
pool.calculating(true);
ec.saveChanges();
System.out.println("setCalculating true " + threadName + " for
pool " + pool.name());
return true;
} else {
System.out.println("checkAndLock returning false " + threadName +
"for pool " + pool.name());
return false;
}
}
}
I've set up each thread with its own editing context, with each
having the same parent ObjectStoreCoordinator using the following
code:
EOObjectStoreCoordinator parentObjectStore = new
EOObjectStoreCoordinator();
EOEditingContext thread1EditingContext =
ERXEC.newEditingContext(parentObjectStore);
EOEditingContext thread2EditingContext =
ERXEC.newEditingContext(parentObjectStore);
EOEditingContext thread3EditingContext =
ERXEC.newEditingContext(parentObjectStore);
This is the call thread1 makes:
poolSync.checkAndLockForCanIWins(pool, threadName,
thread1EditingContext)
While the synchronized class seems to work as expected based on my
IO output below, the editing contexts in each thread don't seem to
be being kept up to date with states set from other threads. I
was under the impression that WO would do this for me
automatically as soon as saveChanges was called as long as they
shared the same parent ObjectStoreCoordinator. Is that not the
case?
Note that even though thread 1 sets pool.calculating to true for
TESTPOOL, threads 2 and 3 later read the pool.calculating() state
as False.
checkAndLock called by Thread 1for pool TESTPOOL
setCalculating true Thread 1 for pool TESTPOOL
checkAndLock called by Thread 3for pool TESTPOOL
setCalculating true Thread 3 for pool TESTPOOL
checkAndLock called by Thread 2for pool TESTPOOL
setCalculating true Thread 2 for pool TESTPOOL
Couple off the cuff guesses:
- is Pool an EO? You need to unlock (and then relock) the EC to
see changes saved in other editing contexts. IIRC, locking then
unlocking has the same effect without actually unlocking the EC.
- if Pool is not an EO, is calculating declared transient?
Chuck
--
Chuck Hill Senior Consultant / VP Development
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
--
Chuck Hill Senior Consultant / VP Development
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden