O$6.1.1: Problem with object references stored in list
Vik Shah
Vik at Keys2Solutions.com.au
Mon Mar 2 22:18:54 EST 2015
Hello Greg,
I am not sure its entirely omnis.
Here what I think you can do to debug this...
1. Why not try to perform a stack dump in the $destruct of an object so that you can see what is causing it to destruct.
2. breaking the code by using a hard breakpoint and see the method stack.
3. test for valid reference before you go in, objref.$validref()
4. in every object you create a newer() for, store the remote task instance’s name & ident. That will tell you visually if that remote task is still present or dead and you can also log that info in the $destruct.
5. I am not sure if this will work, but set the $selfcontained property true on the test object and then you can store the various states of that object into a file/database/anything in binary form. This gives you the innate ability to re-incarnate those objects at that exact point in time they were killed off.
Try these before you report, who knows you may be able to find out why/when/where/what about this behaviour.
Regards,
Vik Shah
Director
Keys2Solutions
> On 2 Mar 2015, at 05:33, Grzegorz (Greg) Pasternak <grzegorz at niagara.com> 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.
>
>
>
> On Mar 1, 2015, at 1:33 PM, Doug Easterbrook <doug at artsman.com> wrote:
>
>> hi Greg:
>>
>> I can't tell you if its a bug or not -- but I do recall that there is some comment in the release notes about doing object reference counting and then deallocating the reference when the object goes away. The release note read-me says:
>>
>>
>> - Object references auto delete
>> Object references are now deleted automatically when they are no longer required in order to free up memory
>>
>>
>> that might be what is getting you -- this change in behaviour where your object is no longer existing -- the references may magically go too.
>>
>>
>> Doug Easterbrook
>> Arts Management Systems Ltd.
>> mailto:doug at artsman.com
>> http://www.artsman.com
>> Phone (403) 536-1205 Fax (403) 536-1210
>>
>>> On Mar 1, 2015, at 9:10 AM, Grzegorz (Greg) Pasternak <grzegorz at niagara.com> wrote:
>>>
>>>
>>> I have the code that stores object reference in the list. The list is stored in task variable that is instantiated in Startup.
>>> In the same library there is Remote task that is instantiated to handle HTTP request.
>>>
>>> Part of the request processing is to use object reference that has been created and is stored in the task variable.
>>> I have noticed that upon searching the list for stored object reference inside the task variable the object reference gets destroyed.
>>> As a result the returned object reference is NULL.
>>>
>>> The above mechanism is working pretty well in Omnis Studio 5.1.
>>>
>>> Has anybody observed the above behavior?
>>> The manual clearly states that object references can be stored in lists and reused unless explicitly deleted or library closed.
>>>
>>> Could it be that this is the new bug introduced in Studio 6.1.1 ?
>>>
>>> Regards;
>>> Greg
>>>
>>> _____________________________________________________________
>>> Manage your list subscriptions at http://lists.omnis-dev.com
>>
>> _____________________________________________________________
>> Manage your list subscriptions at http://lists.omnis-dev.com
>
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
More information about the omnisdev-en
mailing list