Hey!
On Tue, 1 Aug 2000 12:51:03 -0400, James Cook <[EMAIL PROTECTED]> wrote:
>----- 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.
Pretty much, yes.
>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!?
Nope. Timestamps can be used to resolve that. This will, of course, only
work with CMP where you can have control over how database tables are
created (to include timestamp columns).
>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.
No, the update notifications to the caches to drop stale data can be
sent asynchronously. If the notification comes before an access is made,
then all is fine. If not (and which is the problem you are referring
to), there can be two situations: with a read, stale data will be read.
This may be ok in some situations. With a write, the timestamping will
detect that another cache has changed the data, and a rollback will
occur.
I don't claim it to be perfect, but I do think that it is a very
valuable technique for read-mostly scenarios, and from what I know
read-mostly scenarios are fairly common in web apps.
>> 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. :-)
Yes. The "more details" I referred to is basically the timestamping
outlined above. (and now you're going to say that the "outline" is too
vague too... ack.. ;-)
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
===========================================================================
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".
