Hello there,

just the very now, I have bumped into a weird problem.

I run some DB-intensive background tasks. So as they do not block the whole 
application, I set up 
er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators > 1, and my code

(a) gives one of the coordinators to all sessions (through 
sess.defaultEditingContext=ERXEC.newEditingContext(osc))

Since sessions rarely or never do long selects/inserts/whatever, there's no 
harm they share the coordinator.

(b) the background threads each get one of the remaining coordinators

Thus, the background threads (which _do_ _very_ long selects; actually, they do 
ERXEOControlUtilities.objectCountWithQualifier, involving joins) might block 
one another, but never block the sessions.

So far, it worked well. Today, in session, I used the ERXExistsQualifier -- and 
it looks like its usage blocks somehow until the background threads (which use 
different coordinators -- I did check) are done?!?

To me, it does not make any sense, but it works like this -- the following code 
(where qualifiedEOsSVM is just a thin shell over objectsWithFetchSpecification)

=== 1 ===
def me=new 
EOKeyValueQualifier('user',EOQualifier.QualifierOperatorEqual,session.currentUser)
def hasme=new ERXExistsQualifier(me,'userLinks')
Log "FETCH STARTS ..."
all=DBGenGeneratedItem.qualifiedEOsSVM(DBGenGeneratedItem, hasme, 
session.defaultEditingContext())
Log "...FETCH ENDS"
===

logs out something like this -- always the delay betw. the 1st and 2nd log 
(here about 4 seconds) is big, and always it is full of the thread logs:

=== 1 log ===
18:09:42.129 WARN  FETCH STARTS...       //log:NSLog [WorkerThread11]

... lots of “background-thread-did-end” logs here ...

18:09:46.936 DEBUG  === Begin Internal Transaction       //log:NSLog 
[WorkerThread11]
18:09:46.936 DEBUG  evaluateExpression: ... proper one with EXISTS ...      
//log:NSLog [WorkerThread11]
18:09:46.938 DEBUG 5 row(s) processed       //log:NSLog [WorkerThread11]
18:09:46.938 DEBUG  === Commit Internal Transaction       //log:NSLog 
[WorkerThread11]
18:09:46.944 WARN  ... FETCH DID END       //log:NSLog [WorkerThread11]
===

If I do not launch the threads at all, the log is always as expected, i.e., 
something like this (compare the delay)

=== 1 log, no background threads exist ===
18:14:35.079 WARN  FETCH STARTS...       //log:NSLog [WorkerThread4]
18:14:35.080 DEBUG  === Begin Internal Transaction       //log:NSLog 
[WorkerThread4]
===

If, instead of using the ERXExistsQualifier, I simply fetch all the rows and 
filter them programmatically, something like

=== 2 ===
def fs=new EOFetchSpecification('DBGenGeneratedItem',null,null)
NSLog.err.appendln "FETCH STARTS..."
all=session.defaultEditingContext().objectsWithFetchSpecification(fs)
NSLog.err.appendln "... FETCH DID END, FILTERING ..."
all=all.findAll {
    it.userLinks.find { sess.currentUser==it.user }
}
NSLog.err.appendln "... FETCH AND FILTER DID END"
===

and run all the background threads as usually, _there is no delay again_, the 
log looks like this:

=== 2 log ===
18:18:49.722 WARN  FETCH STARTS...       //log:NSLog [WorkerThread8]
18:18:49.722 DEBUG  === Begin Internal Transaction       //log:NSLog 
[WorkerThread8]
18:18:49.722 DEBUG  evaluateExpression: ... SIMPLE ONE ...       //log:NSLog 
[WorkerThread8]
18:18:49.723 DEBUG 6 row(s) processed       //log:NSLog [WorkerThread8]
18:18:49.723 DEBUG  === Commit Internal Transaction       //log:NSLog 
[WorkerThread8]
18:18:49.731 WARN  ... FETCH DID END, FILTERING ...       //log:NSLog 
[WorkerThread8]
18:18:49.737 DEBUG  === Begin Internal Transaction       //log:NSLog 
[WorkerThread8]
18:18:49.737 DEBUG  evaluateExpression: ... SELECTing userLinks for 1st item 
...       //log:NSLog [WorkerThread8]
18:18:49.738 DEBUG 0 row(s) processed       //log:NSLog [WorkerThread8]
18:18:49.738 DEBUG  === Commit Internal Transaction       //log:NSLog 
[WorkerThread8]
... etc, other SQL transactions to select userLinks for the other items when 
filtering ...
18:18:49.750 WARN  ... FETCH AND FILTER DID END       //log:NSLog 
[WorkerThread8]

... lots of “background-thread-did-end” logs here ...
===

I must frankly admit I have no idea what the darn happens there -- it looks 
like there is some weird ERXExistsQualifier pre-processing, which waits for all 
the background threads which fetch inside different store coordinators?!?

Does it make any sense?

Thanks for any advice,
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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to