O$6.1.1: Problem with object references stored in list

Bastiaan Olij bastiaan at basenlily.me
Sun Mar 1 16:49:58 EST 2015

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.



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.

More information about the omnisdev-en mailing list