Chris Raber wrote:
>
> Assaf,
>
> One conceptual disconnect we may be having is the the GemStone/J cache
> itself is transactional. This means updates to the cache and other XA
> resources are performed in a 2PC distributed transaction. Does this ease
> your worry of coherency issues?
I took it for granted that your stuff is transactional and maintains
full ACID-ity. You will see the mechanisms at work in the Castor cache
engine.
But you have to assume that the application is not developed entirely
through this architecture, for a variety of reasons, one of them being
scalability. So you have to assume your entity beans are updated outside
of your control.
Once you made that assumption, the only two models I see working are
those that I described, of hard locking and dirty checking. Hard locking
does not require a shared cache, since you always synchronize with the
database (just in case). Dirty checking does not require a shared cache,
since it can always be invalid to begin with.
Considering the cost (object passing over TCP/IP) I just fail to see the
benefit.
> Of couse we still have the issue of optimistic locking/dirty checking for
> updated that are buffered between transactions... That pattern applies
> whether we have distributed caching and XA or not...
Yep.
arkin
>
> -Chris.
===========================================================================
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".
