----- Original Message -----
From: "Rickard �berg" <[EMAIL PROTECTED]>
> I'll try, but it's hard to explain in detail. Let each
> cluster node to Option A (i.e. cache data). When a
> change has been made in an entity in one node, the
> other nodes are notified that the entity with the
> particular pk has changed. If they have that entity
> the data is marked as invalid. When a new transaction
> with that entity is started on one of the "flushed"
> cluster nodes, its data will simply be reloaded from
> the db. That's the basic idea anyway.
I won't say that this is impossible, since I don't have the ego to know
everything that is or is not. I'll just say it seems impractical without
sacrificing performance and scalability. You stating that (deep breath) a
shared cache can be implemented as a bunch of individual caches where all
caches are told to drop there cached value, if that value changes in one of
the caches. whew.
The mechanism that you propose will assume that you can (and will have to)
lock access to all nodes, whenever one of the nodes is written to!?
Otherwise, two simultaneous threads could access stale data before the node
it is hitting gets notified of the change in the other node. Doesn't work
without the synchronization, and multi-vm/multi-machine synchronization is
many times more inefficient than letting the database cache.
> There are more details involved with how to make sure that
> the nodes don't overwrite each others data if two concurrent
> tx's modify the same entity.
Gotta finish reading before I start writing...This is the point to which I
refer. I think "...more details involved..." is an understatement. :-)
jim
===========================================================================
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".
