On Dec 11, 2006, at 6:52 AM, Kieran Kelleher wrote:
Freshen the current editing context is easy ...
editingContext.setFetchTimestamp( new java.util.Date().getTime() );
Now any EO's that you touch will be refreshed if their fetch
timestamp is older than the time at which you executed the
Freshen the current editing context is easy ...
editingContext.setFetchTimestamp( new java.util.Date().getTime() );
Now any EO's that you touch will be refreshed if their fetch
timestamp is older than the time at which you executed the above
statement.
On Dec 9, 2006, at 9:48 AM, Dov R
On Dec 9, 2006, at 6:48 AM, Dov Rosenberg wrote:
The main reason for my question centers around the fact that in
some places
of our app we needed to use JDBC directly for performance reasons
(mainly
the bulk operations). Of course when that happens the object graph
can get
out of sync wit
The main reason for my question centers around the fact that in some places
of our app we needed to use JDBC directly for performance reasons (mainly
the bulk operations). Of course when that happens the object graph can get
out of sync with reality.
All editingcontexts (including the shared editi
On 09.12.2006, at 05:26, Chuck Hill wrote:
invalidate: tosses the snapshot, affects all editing contexts.
Forces the data to be refetched from the database.
You can invalidateObjectsWithGlobalIds. Then you have more control
over what is invalidated. We use this for a patched implementation
This always makes my head hurt, but I will take a stab at it.
invalidate: tosses the snapshot, affects all editing contexts.
Forces the data to be refetched from the database.
refault: changes the eo back into a fault in the EC. Depending on
the EC's fetch timestamp and the snapshot's age
What is the difference between Invalidating an object versus refreshing
versus refaulting?
It seems that some of the methods call the others. Any commentary on which
should be used and when would be appreciated. Thanks in advance
--
Dov Rosenberg
Conviveon/Inquira
Knowledge Management Experts
h
