That's a good point, the solution with localInstanceIn() works till I access
the record within the defaultEC again. Then I have a deadlock.
I have created the first record an send the global Id to the thread:
final EOGlobalID globalId = defContext.globalIDForObject(myObject);
new Thread() {
public void run() {
EOObjectStoreCoordinator oc = new EOObjectStoreCoordinator();
EOEditingContext ec = new EOEditingContext(oc);
ec.lock();
try {
MyObject movedObject = ec.faultForGlobalID(globalId, ec);
// do something
} finally {
ec.unlock();
}
}
}.start();
Seems to work. The screencast was very interesting.
Thank you
Andre
Von: René Bock <[email protected]>
An: Paul Hoadley <[email protected]>
Kopie: WebObjects-Dev <[email protected]>
Gesendet: 13.10.2017 10:13
Betreff: Re: Object registered within another EditingContext
Hi,
just creating a new EOEditingContext for the background task may lead to nasty
deadlocks, as this EC refers to the default object store. As an ec.lock()
locks its object store, so locking the ec in the background task has a side
effect to the ECs in the main (worker) thread.
You may consider to use ERXTask, which relies on a separate object store
coordinator. (there is nice screencast about this topic in the WOCommunity
space)
The downside will be, that you have more open database connections and an
increased heap footprint.
Am 13.10.2017 um 00:42 schrieb Paul Hoadley <[email protected]>:
Hi André,
On 13 Oct 2017, at 04:53, André Rothe <[email protected]> wrote:
Then I have created a thread with a new EditingContext to insert a lot of
detail records, which have a reference to the first inserted record.
You need to take some additional care when working in a background thread.
1. Don’t pass an existing EOEditingContext into a background thread, create a
new one—you’re doing this.
2. Don’t pass existing EOs into a background thread, pass in the object’s
EOGlobalID, and then get the object in the thread using that ID.
* ERXEOControlUtilities.convertEOtoGID()
* ERXEOControlUtilities.convertGIDtoEO()
3. There are some classes in er.extensions.concurrency that you might find
helpful, though I’ve never used them. If you just want to use regular Java
concurrency features, remember to handle EC locking/unlocking yourself:
ec.lock();
try {
// ...
} finally {
ec.unlock();
}
(On the main thread, Wonder handles locking/unlocking for you.)
--
Paul Hoadley
https://logicsquad.net/
https://www.linkedin.com/company/logic-squad/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/bock%40salient-doremus.de
This email sent to [email protected]
Mit freundlichen Grüßen
René Bock
--
Telefon: +49 69 650096 18
salient GmbH, Lindleystraße 12, 60314 Frankfurt
Telefon Zentrale: 069 / 65 00 96 - 0 | www.salient-doremus.de
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/andre.rothe%40zks.uni-leipzig.de
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
