Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

November 2003 Journal Article Discussion - The Distributed Cache Pattern

 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, it helped! Thanks!
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic