You may also try to fetch without the exists qualifier and apply it in memory
on the fetched objects to see if the locking will append too.
I looked a bit into the code and there is at least a global lock involved in
the execution, EOModel._EOGlobalModelLock. These are in methods to get
informations about the model so I expect the lock to be very shorts
If you can create a repeatable case and be able to suspend the program during
the pause, you will at least be able to find out where it append.
There is probably better way to investigate locking problems but I do not know
> Le 13 oct. 2016 à 12:39, OC <o...@ocs.cz> a écrit :
> To be sure where the delay happens, I have tried to re-write the code  to
> === 1 ===
> def me=new
> def hasme=new ERXExistsQualifier(me,'userLinks')
> def fs=new EOFetchSpecification('DBGenGeneratedItem',hasme,null)
> NSLog.err.appendln "FETCH STARTS..."
> NSLog.err.appendln "... FETCH DID END"
> and still the delay (which looks like waiting for the beackground threads)
> happens in betwixt "FETCH STARTS" and "=== Begin Internal Transaction".
> Thus, it is self-evident it happens somewhere in
> objectsWithFetchSpecification, if (and only if!) the qualifier contains
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjectsfirstname.lastname@example.org)
> Help/Unsubscribe/Update your Subscription:
> This email sent to sam...@samkar.com
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjectsemail@example.com)
Help/Unsubscribe/Update your Subscription:
This email sent to arch...@mail-archive.com