Yeah I'd say it is superfluous in the recommended configurations (i.e.
if you bind a context to a session, and logging out equals session
termination).
Andrus
On Jun 8, 2010, at 8:15 AM, Joe Baldwin wrote:
> Andrus,
>
> I read this post by you and am wondering should I initiate an
> "unregisterObjects" in the normal course of events, when say someone
> is logging out (in a webstore design pattern) to "suggest" memory
> management events, or is that superfluous and your "weak reference"
> algorithm is sufficient?
>
> Joe
>
>
> On Jun 7, 2010, at 11:04 AM, Andrus Adamchik wrote:
>
>> Invalidate should hollow the objects, but keep their references in
>> the context (they shouldn't resolve to committed though, so I am
>> surprised about that).
>>
>> DataContext also has a method "unregisterObjects" (not a part of
>> ObjectContext interface) that should forget about the objects in a
>> given context, clear the shared cache, and send invalidate event to
>> peer contexts.
>>
>> Andrus
>>
>>
>> On Jun 7, 2010, at 7:58 AM, Tore Halset wrote:
>>
>>> Well, processSnapshotChanges did not solve the problem either. I
>>> am now doing deleteObjects() after deleting them via plain jdbc.
>>> It is not pretty, but works well as long as the objects are in
>>> state COMITTED.
>>>
>>> - Tore.
>>>
>>> On Jun 7, 2010, at 12:27, Tore Halset wrote:
>>>
>>>> Hello.
>>>>
>>>> This one seem to work much better.
>>>>
>>>> ((DataContext)
>>>> ctxt
>>>> ).getObjectStore().getDataRowCache().processSnapshotChanges(this,
>>>> Collections.EMPTY_MAP, deletedIds,
>>>> Collections.EMPTY_LIST,
>>>> Collections.EMPTY_LIST);
>>>>
>>>> - Tore.
>>>>
>>>> On Jun 7, 2010, at 09:27 , Tore Halset wrote:
>>>>
>>>>> Hello.
>>>>>
>>>>> I am deleting some rows via jdbc and want to update the cayenne
>>>>> stack with that information. After issuing
>>>>> ctxt.invalidateObjects(...) the cayenne objects for the deleted
>>>>> rows still have persistence state comitted. Is there a better
>>>>> trick than invalidateObjects(...)?
>>>>>
>>>>> - Tore.
>>>>
>>>>
>>>
>>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Tue Jun 08 2010 - 15:42:59 UTC