Re: [Wonder-disc] Discuss: Utility of _datesPerEcID in ERCStampedEnterpriseObject

[Camille T. <ca...@od...>]

Hi Max,

Thanks for your lights.


On Monday, Nov 4, 2002, at 19:01 Europe/Paris, Max Muller wrote:

>> I have borrowed a part of ERCStampedEnterpriseObject's implementation 
>> in a class I have called OFDatedEntity. The user of this abstract 
>> class is to provide EOs with optimistic locking handling : In 
>> EOModeler, only two rows have the lock enabled, the primary key row, 
>> and the lastModified row.
>
> If you take that approach then you just need to make sure that you 
> have all of your inverse relationships modeled so that your eo will 
> always be "touched" when a relationship to it changes, else you could 
> not detected a relationship change and stomp over a previous commit.

That's very interesting !  Unfortunatley, I forgot that detail.
When I look at my model, I have something like this :

	Campaign <----->> Participants

A campaign can have over millions of participants, that's I didn't set 
the reverse relationship, and I don't use 
addObjectToBothSidesOfRelationshipWithKey because it seems that EOF 
tries to fetch all the participants (and thus overflowing the memory).  
I only use setCampaign on the desired participant.

Do you have a solution to this problem ?

> The dictionary does not hold a reference to the editing context, 
> instead it holds the system unique hash code of the editing context. 
> You are correct that this dictionary will continue to grow over time 
> and not be cleaned up. We could correct this issue in three ways a) 
> right now we hold references to all the editing contexts created for a 
> session until that session has been garbage collected, this was done 
> to avoid the "attempt to message eo that has had their editing context 
> freed", so when this dictionary is freed we could post a notification 
> that the editing context will be freed, then in ERCore we have a 
> handler that removes the entry for that ec from the dictionary b) we 
> use a WeakHashMap with a direct reference to the editingcontext c) we 
> subclass EOEditingContext and post a notification in the finalize() 
> method of the ec. Personally I would lean towards a) or b).

b) is the best method I think.


>> If we used an integer that would be incremented every time it was 
>> updated, we would not need to use the _datesPerEcID and there would 
>> be no dependancy over datetime (timestamp) precision.
>
> If you just wanted a transaction id that is incremented and set on all 
> of the objects then you could actually just use an editing context 
> delegate and in editingContextWillSaveChanges just increment the 
> transaction id and set that value on all inserted, updated and deleted 
> objects in the editing context. Might be a simpler solution.

You're right, but you don't mention anything about the problem I have 
with TIMESTAMP, do you have an opinion on it?


Thanks again, Max.

Best Regards,
Camille