• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: multi-instance: orphaned fault
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multi-instance: orphaned fault


  • Subject: Re: multi-instance: orphaned fault
  • From: OC <email@hidden>
  • Date: Tue, 20 Jan 2015 15:55:31 +0100

Ken,

On 20. 1. 2015, at 15:37, Ken Anderson <email@hidden> wrote:

> Is there a reason you’re storing the result of the relationship instead of the source?  If you stored one level up, you’d properly get a null result instead of a stale fault.

Absolutely -- "If I wrote my code afresh, I could make sure this never happens".

But the problem is that "I've got zillions of legacy Java lines in my project (which might store faults freely, after all, that's what faults are for)".

Thanks,
OC

> On Jan 20, 2015, at 8:01 PM, OC <email@hidden> wrote:
>> Hello there,
>>
>> I've just bumped into a new problem. Unless I am doing something wrong, it does not seem the remote synchronizer helps in this scenario; and I wonder, whether there are some well-known and common tricks to solve it in general?
>>
>> The scenario is quite plain:
>>
>> (a) instance A gets and stores (typically into some sort of cache, but a plain component property suffices[*]) a relationship of some EO for the first time. Thus, it, in fact, gets and stores a fault;
>>
>> (b) instance B updates "some EO" to clean up the relationship and deletes the target object.
>>
>> - the Remote Synchronizer does make sure that "some EO"'s relationship is NULL now in instance A;
>> - nevertheless, it does not do anything at all with the stored fault
>>
>> (c) instance A uses the stored "EO" (which its code essentialy does not know is a fault) -- and oops, it gets DatabaseContextDelegate.databaseContextFailedToFetchObject.
>>
>> (Well one wonders, whether this might be the reason why WebObjects by themselves do not throw when a fault fails, but try to re-construct the object _somehow_)
>>
>> Anyway, to be quite frank, I don't see a decent solution of this problem? If I wrote my code afresh, I could make sure this never happens, but since I've got zillions of legacy Java lines in my project (which might store faults freely, after all, that's what faults are for), I don't see a solution which would ensure my application can't fail and either work improperly or report weird errors to users.
>>
>> Has anybody already found a decent solution of this problem (save for “re-writing all the legacy code”, which, albeit of course optimal, is sort of not manageable any time soon)?
>>
>> Thanks a lot,
>> OC
>>
>> ===
>> [*] like with a very plain code -- the real cases are much more complex, but this one suffices to show the problem
>>
>> class MyComponent extends ERXComponent {
>> SomeEOClass stored;
>> public MyComponent(WOContext context) {
>>   super(context);
>>   stored=someEO.someRelationship();
>> }
>> public WOComponent nowUseIt() {
>>   println "$stored"
>> }
>> }
>>
>>
>>
>> _______________________________________________
>> 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


References: 
 >multi-instance: orphaned fault (From: OC <email@hidden>)
 >Re: multi-instance: orphaned fault (From: Ken Anderson <email@hidden>)

  • Prev by Date: Re: multi-instance: orphaned fault
  • Next by Date: Re: WOWODC 2015
  • Previous by thread: Re: multi-instance: orphaned fault
  • Next by thread: Re: multi-instance: orphaned fault
  • Index(es):
    • Date
    • Thread