Re: global EO representant / locking on EO?
Re: global EO representant / locking on EO?
- Subject: Re: global EO representant / locking on EO?
- From: Ramsey Gurley <email@hidden>
- Date: Mon, 02 Mar 2015 09:37:16 -0700
What you are asking about is the EC that shall not be named. Nobody uses it. It’s the bane of WO’s existence. Usage of this EC encourages what I once heard referred to as the “EO Constant idiot pattern.” It causes strange errors throughout your code and will decimate your concurrent performance. If you are foolhardy enough to even look upon it, then here it is. Be warned, once you do this, you will want to cleanse your vision by staring directly at high powered lasers for a few hours.
http://wocommunity.org/documents/javadoc/WebObjects/5.4.2/com/webobjects/eocontrol/EOSharedEditingContext.html
If you prefer not to ruin your application, then there was a WOnder-ish workaround known as the ERXConstant
https://jenkins.wocommunity.org/job/Wonder/javadoc/er/extensions/eof/ERXConstant.html
But in my opinion, all of this was eclipsed by Java 1.5’s Enum. Assuming your relationship to this global is a to-one, then you can model the enum as an attribute. That is what I would recommend over other approaches.
On Mar 2, 2015, at 2:39 AM, OC <email@hidden> 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@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden