"Jonathan K. Weedon" wrote:
>
> ...
> > (1) Put a timestamp (e.g. System.currentTimeMillis()) into your fat keys, so
> > you can detect stale data based on timeouts (for read-only transactions).
>
> I don't see how a timeout helps. System time is measured in milliseconds. It
> is very much possible for my evil case (get the obj ref in one transaction, use
> it in another) could all perform within a millisecond. So, I don't think timeouts
> fix the problem, although they do make it less frequent, perhaps.
Unless you use pessimistic locking (e.g. locking the database row(s) during
ejbLoad), for a read-only transaction there is a possibility that by the end
of the transaction the underlying DB data will have changed. So if you put
a timestamp in your 'FatKey' and avoid hitting the DB in some cases (for
read-only transactions), all you have done is extend the amount of time in
which you allow DB data to change after its initial retrieval. Either way,
the DB data may have changed by the time your transaction commits. So I
would argue that in any situation where you are not using pessimistic locking
for ejbLoad, the customer can define an "acceptable timeout period" for
possibly stale data that is used by read-only reansactions. If this timeout
period happens to be 15 seconds or one minute, you could get a lot of caching
benefit.
________________________________________________________________________________
Evan Ireland Sybase EAServer Engineering [EMAIL PROTECTED]
Wellington, New Zealand +64 4 934-5856
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
