O$6.1.1: Problem with object references stored in list

Grzegorz (Greg) Pasternak grzegorz at niagara.com
Mon Mar 2 09:30:39 EST 2015


Hi Bas;

Thanks for your comments.
I think the new feature in O$6.1.1 is not perfect yet and the implemented object references cleanup is ignoring these object references that are stored in the list.  I am sure Tigerlogic will look into this problem and possibly have the some solution in next release.   

On the other topic, is is finally getting warm here (around -7C) and the snow situation seems to be improving!

Regards;

Greg



On Mar 1, 2015, at 4:49 PM, Bastiaan Olij <bastiaan at basenlily.me> wrote:

> Hi Greg,
> 
> It sounds to me there may be a hole or two in the reference counting.
> Maybe its not accurately doing so when you store a reference in a list.
> Its gottah be hard to retrofit that because of the way you can copy
> lists around and the reference counting mechanism may be overlooking
> this. I would definitely submit this to TigerLogic support.
> 
> Knowing all the pitfalls that you can step into when implementing
> reference counting for the first time (I've rolled my own in Studio 4
> using retain/release patterns) it isn't hard to think or fault
> TigerLogic for not perfecting this right off the bat. I would not be
> surprised if it explains one or two crashes I've been experiencing.
> 
> But 6.1 is new and the number of internal changes Bob hinted at at
> EurOmnis are staggering. While frustrated with some of the issues we've
> run into so far (and we've only just started trying to move to 6.1) my
> hat is off to what they are doing in both 6.1 and 6.2 and I can only
> respect the difficulty level involved. These are teething problems that
> should have been caught during beta testing (and I for one am looking in
> the mirror for not taking more time out to help our friends at Mitford
> house more by taking advantage of the beta program) but will undoubtedly
> be fixed shortly. As early adapters of new versions we unfortunately sit
> on the front lines of issues like these.
> 
> Cheers,
> 
> Bas
> 
> On 2/03/2015 6:33 am, Grzegorz (Greg) Pasternak wrote:
>> Yeah, I thought about this.
>> However the problem is that I want to "cache" the object state (effectively this instance of an object) between remote task instances (aka different requests).  The objective is to instantiate object dynamically in one request, then keep it until some other request comes in and does some stuff, finally the object will be explicitly deleted in some other request explicitly.
>> 
>> I have chosen to store object reference instance in the list as it is unknown how many objects reference instances will be needed in this sequence of events (requests).
>> 
>> I am pretty sure that the object reference instance is instantiated in the Startup task which should guarantee that it should be alive when Remote task instance dies.  I can actually see it inside the list but as soon as attempt to access it Omnis will destroy it and I get into the $distruct method.  Needless to say this is not what I want.
>> 
>> So the question is: how can I prevent Omnis from making assertion that the object reference is no longer required?
>> 
>> Turning around the question, is there an alternative way to achieve the caching of the state of the object between different Remote task requests.
>> More importantly, how can I dynamically control this?
>> 
>> I suppose I could create variables like iObj1Ref, iObj2Ref, and so on and use them for caching state rater than storing in the list.
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com




More information about the omnisdev-en mailing list