>1. Read only objects, cache unlimited. They shouldn't
>be locked, so for them distributed cache should work
>just broadcasting updates.
I don't think it is true. You probably mean something
else when you say lock.
All objects that involve in a transaction must be locked.
Please take a deeper look on the LockEngine.
>2. cache time-limited objects should just ignore
>distributed updates.
I don't agree on that either. The time-limited maybe
very long, because the chance it is change is very
small. But, when it is updated, we should attempts
to evict the object as soon as possible. I said asap,
because the object might be locked by a transaction.
>3. Database-Locked access should be reread every time
>from database, another why they are db-locked.
Yes, it is already done. It doesn't influence with cache.
>4. Long transactions via timestampable interface
>should
>be invalidated, because their master record changed.
Yes, but there is no reason to treat those cache differently.
>5. Pessimistic transaction in case of distributed cash
>should acquire distributed lock using shared table or
>broadcasting. This will be slow.
We are not attempting distributed locks, as I mentioned.
The database itself is our distributed lock. We do dirty
check on every update to detect if object is modified by
other application.
>6. It will be nice to implement optimistic transaction
>which will copy object into local transaction session
>and merge them back into main cache on commit.
>Drawback is copying objects.
I don't think we should attempt it.
Thomas
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
