Hi again,
ERXGenericRecord has permanentGlobalID() which returns a EOKeyGlobalID
that might give you the unique instance you want.
Is there something that prevents you from isolating the processing code
in its own method/class that is called by all threads and is guarded by
a lock of your choice?
Cheers, Bogdan
On 02/03/2015 11:29, OC wrote:
Bogdan,
On 2. 3. 2015, at 11:00, Bogdan Zlatanov <[email protected]> wrote:
This response will not be very helpful, but this sounds like an X-Y problem.
Could you elaborate more on what exactly you'd like to achieve?
To have a code into which "no two threads would get with same EO, not even if the EO
is in different ECs".
Namely, to perform some processing based on particular EO (or its global ID or
its PK), which processing needs to be either atomic, or covered by optimistic
locks and rejectable. Since the latter would be rather difficult, and since the
processing is not terribly time-consuming, and since the app is
single-instance, I would opt for the atomicity, if I knew how.
(Well meantime I have found
http://illegalargumentexception.blogspot.cz/2008/04/java-synchronizing-on-transient-id.html
which probably would help with PK, just seems unnecessarily convoluted...)
Thanks,
OC
On 02/03/2015 10:39, OC wrote:
Hello there,
is there an object whose _instance_ (not just value like it seems to be with
the global ID) would consistently represent one EO, regardless the EC in which
the EO just happens to be?
I would need to lock on an EO, but I would need that it worked over all ECs,
i.e.
===
synchronized (eo) {
// no two threads would get there with same EO
// _not even if the EO is in different ECs_
// which is why 'synchronized (eo)' does not work
}
===
Of course, I could make a thread-safe map, insert lock objects there and use
globalids for index, but it seems to me rather convoluted -- not speaking of
that I would not really know when to flush the data (unless I override EOs
finalize, ick...)
Isn't there a better solution?
Thanks a lot,
OC
_______________________________________________
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/bogdan.zlatanov%40gmail.com
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/ocs%40ocs.cz
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]
