Bogdan,
On 2. 3. 2015, at 12:05, Bogdan Zlatanov <[email protected]> wrote:
> ERXGenericRecord has permanentGlobalID() which returns a EOKeyGlobalID that
> might give you the unique instance you want.
Aha... is that guaranteed? That would be easier, but quickly checking the
Wonder sources I got an impression that different instances of the EO in
different ECs might return different (although reliably equal) instances of
global ID.
But as always, I might have missed something of importance.
> 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?
I can use a lock of my choice; my problem was to find a lock which would have
the desired feature that it is reliably the same instance for all EOs which
represent the same object (regardless the EC).
Nevertheless, meantime I've created the following code (based on the blogspot
linked below), which preliminarily seems to work well -- note that I lock (a)
only objects of one entity, (b) already saved to DB, and thus can rely on PK --
can't bump into different entities, can't bump into null PK.
Still, if someone happens to see any problem there, I'll appreciate a nudge :)
===
static private __locks=new WeakHashMap()
static private auctionLock(DBAuction auction) {
Integer id=auction.primaryKeyNumericValue // has been saved -> is
unique and nonzero
synchronized(this.@__locks) {
def lockwr=this.@__locks[id]
if (lockwr) return lockwr.get()
def lock=new Integer(id)
this.@__locks[lock]=new java.lang.ref.WeakReference(lock)
return lock
}
}
...
synchronize (auctionLock(auction)) {
... this code never runs concurrently for same auction, regardless its
EC ...
}
===
Thanks a big lot,
OC
> 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]
