It's not a secret anymore!*
The moose likes OO, Patterns, UML and Refactoring and the fly likes November 2003 Journal Article Discussion - The Distributed Cache Pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "November 2003 Journal Article Discussion - The Distributed Cache Pattern" Watch "November 2003 Journal Article Discussion - The Distributed Cache Pattern" New topic
Author

November 2003 Journal Article Discussion - The Distributed Cache Pattern

Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
JavaRanch's Kyle Brown has included an excellent article in the November issue of the JavaRanch Journal on The Distributed Cache Pattern.
Any thoughts or feedback on this article?


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Nice article. I like the strategy. We're buying a vendor package that OEMs a commercial distributed cache, but I haven't gotten to see it yet.
The book mentioned about messaging has a website with teasers on the patterns (buy the book to read more). I reference it from my Messaging Patterns page. They have a ton of great little patterns.
I'm curious how to assure that transaction 1 in the source completes before transaction n in another server gets the message and attempts to read the database. If the "n" gets there before the 1st commits, "n" gets old data, no? The latency of messaging and the "set the dirty bit" deferred read would seem to improve the odds, but not guarantee proper sequence.
[ November 16, 2003: Message edited by: Stan James ]

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
This is far from being my special subject, so please excuse me if this is a dumb question:
What exactly does "to have the �put� onto the queue be part of the same transaction as the update to the database (e.g., make the cache a Transactional Client) so that the state of the database does not diverge from the known state of the caches" mean?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Originally posted by Stan James:
Nice article. I like the strategy. We're buying a vendor package that OEMs a commercial distributed cache, but I haven't gotten to see it yet.
The book mentioned about messaging has a website with teasers on the patterns (buy the book to read more). I reference it from my Messaging Patterns page. They have a ton of great little patterns.
I'm curious how to assure that transaction 1 in the source completes before transaction n in another server gets the message and attempts to read the database. If the "n" gets there before the 1st commits, "n" gets old data, no? The latency of messaging and the "set the dirty bit" deferred read would seem to improve the odds, but not guarantee proper sequence.
[ November 16, 2003: Message edited by: Stan James ]

It's pretty simple actually. The way that most all J2EE servers work (and all WOULD work if they followed the spec properly) is that even though the method call to place the message on the queue has completed, the message is not ACTUALLY placed on the queue until the end of the two-phase commit transaction including the database update. That's the beauty of the two-phase commit protocol (Which we get in J2EE for free) -- if either fails, they both roll back. If they both succeed, then everything is peachy.
Kyle


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Originally posted by Ilja Preuss:
This is far from being my special subject, so please excuse me if this is a dumb question:
What exactly does "to have the �put� onto the queue be part of the same transaction as the update to the database (e.g., make the cache a Transactional Client) so that the state of the database does not diverge from the known state of the caches" mean?

Hi Ilja -- this gets to the heart of what it means to do 2-PC in J2EE. I rephrased it in the previous answer, so see if that helps. If it doesn't I'll be glad to post a short section of my upcoming WebSphere book, where I cover this in detail in the transactions chapter.
Kyle
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Yes, it helped! Thanks!
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Kyle, thanks! I'd forgotten that little bit of transactions + MOM. Very cool. The article mentions a couple commercial products. Would this be beyond implementing yourself? Doesn't sound too outrageous. (Course that comes from someone who didn't know about MOM + transactions.) I believe our demands for synchronization would allow a few seconds (or probably minutes) delay getting all in sync.
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Well, I originally did an implementation of this that I intended to put into my WebSphere book (but it didn't make it into the final cut). I seem to remember it took me 2-3 nights to get it working, so it's not that difficult to put into place. I know that customers of mine have built implementations of this in a week or less.
Kyle
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: November 2003 Journal Article Discussion - The Distributed Cache Pattern