On Jan 27, 2015, at 4:19 PM, Chuck Hill <ch...@gevityinc.com> wrote:
> Are you using this?
>
> /**
> * This class implements EOF stack pooling including EOF stack synchronizing.
> * It provides a special ERXEC.Factory in order to work without any changes
> in existing
> * applications. The number of EOObjectStoreCoordinators can be set with the
> * system Property
> <code>er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators</code>.
> * Each Session will become one EOObjectStoreCoordinator and the method
> * <code>newEditingContext</code> will always return an
> <code>EOEditingContext</code>
> * with the same <code>EOObjectStoreCoordinator</code> for the same
> <code>WOSession</code>.
> * This first release uses round-robin pooling, future versions might use
> better algorithms
> * to decide which <code>EOObjectStoreCoordinator</code> will be used for the
> next new
> * <code>WOSession</code>.<br>The code is tested in a heavy multithreaded
> application
> * and afawk no deadlock occures, neither in EOF nor directly in Java.
> *
> * @author David Teran, Frank Caputo @ cluster9
> */
> public class ERXObjectStoreCoordinatorPool {
I think so. From a different thread:
another weird case: this application is run single-instance (but
ERXObjectStoreCoordinatorPool.maxCoordinators=3,
WOAllowsConcurrentRequestHandling=true).
>
>
>
> On 2015-01-27, 3:04 PM, "OC" wrote:
>
> Hello there,
>
> since I wrote an awk script to check whether my OSCs get unlocked properly,
> I've bumped into one very strange thing in the locks.
>
> First, my code is pretty straightforward (assuming we should lock OSC at all,
> which is debatable -- based on http://terminalapp.net/dr-optimistic-locking/;
> Chuck says well all right, though it should be sufficient to catch some
> notifications instead):
>
> ===
> EOEditingContext ec=auction.editingContext()
> EOObjectStore osc=ec.rootObjectStore()
> osc.lock()
> try {
> logln "$osc LOCKED FOR CU $sess.currentUser.login"
> EOEditingContext tempec=ERXEC.newEditingContext()
> ... creating localInstanceIn as needed, updating them as
> appropriate …
Wat?
http://i0.kym-cdn.com/photos/images/newsfeed/000/173/580/Wat.jpg?1315930588
I don’t understand why this would be necessary, and I’m afraid to ask ;-)
Anyway,
//You should be doing this if you want to ensure a peer ec in the same osc
EOEditingContext tempec = ERXEC.newEditingContext(osc);
> tempec.saveChanges()
> println "... saved successfully!"
> } catch (exc) {
> ... reporting and logging error -- does not happen ...
> } finally {
> osc.unlock()
> println "$osc UNLOCKED FOR CU $sess.currentUser.login"
> }
> ===
>
> and in one place in my logs, there is
>
> ===
> 26.1 14:06:03:
> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR
> CU CEZProdej
> ... saved successfully!
> 26.1 14:06:03:
> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR
> CU EPETas
> ... saved successfully!
> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED
> FOR CU CEZProdej
> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED
> FOR CU EPETas
> ===
>
> What the darn?!? This should not be possible, or am I completely missing the
> point of osc.lock()?!? :-O
>
> In the vicinity, all the other logs looks all right, no exception not other
> error reported.
>
> As usual, I'll be pretty grateful for any insight,
> OC
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com
>
> This email sent to ch...@gevityinc.com
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com
>
> This email sent to rgur...@smarthealth.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
