 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Struts - A MVC web framework | | Tomcat - JSP/Servlet container | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | | JSP - A mailing list about Java Server Pages specification and reference | |
Struts & Hibernate
|
|
|
| | | Shared cache best practices? | Shared cache best practices? 2004-01-07 - By sven van't veer
Back
The way I do this is by JMS messageing. The EJB (Session Facade) responsable
for altering the underlying DB after sucessful calls to the entity will send a
JMS message with the PK to be invalidated to a topic. The cache listens to the
topic and invalidates the cache entry with that specific PK.
sven
-- --Original Message-- --
From: Erik Beijnoff [mailto:erik@(protected)]
Sent: Wednesday, January 07, 2004 12:34 PM
To: J2EE-INTEREST@(protected)
Subject: Shared cache best practices?
Im facing a situation where my web server holds a rather extensive cache that
is retrieved from a database. I'm seeking a way to be able to connect as many
web servers as I'd like to that database and let each server be notified of the
updates to the database so that they can keep their caches up to date. I'm
looking for best practices in this area.
I'm aware of that one of the possibilities would be to put the cache on a
common machine that all web servers access. However, this is not quite the
solution I am looking for. The cache does not need to be same for all servers.
On the contrary actually. The system is structured in such a fashion that each
web server only holds in it's cache the information that is requested on that
particular server for the moment. This could mean that each web server has
completely different things in their caches. What I'm looking for is a
signaling system that tells all web servers that are using that particular
database that the data has changed in the database so that they can invalidate
that particular portion of their caches so that it can be reread at the next
request.
I suppose that keeping a separate cache server going also would create a
somewhat rather large amount of overhead, granted, it would though be easier to
gurantee consistency.
One of the options that I'm pondering would be a registration and
deregistration process in a table in the database whenever a new web server
connects to the it, and then let the servers signal updates to all the others
through http or RMI or some other suitable method.
Or is this one of those magic moments where EJB actually would make sense?
Regards Erik Beijnoff
=========================================================================== To
unsubscribe, send email to listserv@(protected) and include in the body of the
message "signoff J2EE-INTEREST". For general help, send email to listserv@(protected)
.sun.com and include in the body of the message "help".
this message contains information that may be privileged and confidential.
unauthorized use, disclosure, dissemination and/or copying are strictly
prohibited. if you are not the intended recipient, please delete this message
and any attachments and notify us immediately. please do not copy this message
or disclose its contents to anyone. thank you.
<HTML xmlns:eXclaimer="http://www.exclaimer.co.uk" xmlns:o="urn:schemas
-microsoft-com:office:office">
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=UTF-16 (See http://UTF-16.ora-code.com)">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-16 (See http://UTF-16.ora-code.com)">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859 (See http://iso-8859.ora-code.com)-1">
<META content="MSHTML 6.00.2800.1264" name=GENERATOR>
<STYLE></STYLE>
</HEAD><BODY bgColor=#ffffff><DIV>
<DIV><SPAN class=765271517-07012004><FONT face=Arial color=#0000ff size=2>The
way I do this is by JMS messageing. The EJB (Session Facade) responsable for
altering the underlying DB after sucessful calls to the entity will send a JMS
message with the PK to be invalidated to a topic. The cache listens to the
topic
and invalidates the cache entry with that specific PK.</FONT></SPAN></DIV>
<DIV><SPAN class=765271517-07012004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=765271517-07012004><FONT face=Arial color=#0000ff
size=2>sven</FONT></SPAN></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-- --Original Message-- --<BR><B>From:</B> Erik Beijnoff
[mailto:erik@(protected)]<BR><B>Sent:</B> Wednesday, January 07, 2004 12:34
PM<BR><B>To:</B> J2EE-INTEREST@(protected)<BR><B>Subject:</B> Shared cache
best
practices?<BR><BR></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=530151715-07012004>Im facing a
situation where my web server holds a rather extensive cache that is retrieved
from a database. I'm seeking a way to be able to connect as many web servers as
I'd like to that database and let each server be notified of the updates to the
database so that they can keep their caches up to date. I'm looking for best
practices in this area.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=530151715-07012004></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=530151715-07012004>I'm aware of that
one of the possibilities would be to put the cache on a common machine that all
web servers access. However, this is not quite the solution I am looking
for. The cache does not need to be same for all servers. On the contrary
actually. The system is structured in such a fashion that each web server only
holds in it's cache the information that is requested on that particular server
for the moment. This could mean that each web server has completely different
things in their caches. What I'm looking for is a signaling system that tells
all web servers that are using that particular database that the data has
changed in the database so that they can invalidate that particular portion of
their caches so that it can be reread at the next request.
</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=530151715-07012004></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=530151715-07012004>I suppose that
keeping a separate cache server going also would create a somewhat rather large
amount of overhead, granted, it would though be easier to gurantee
consistency.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=530151715-07012004></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=530151715-07012004>One of the options
that I'm pondering would be a registration and deregistration process in a
table
in the database whenever a new web server connects to the it, and then let the
servers signal updates to all the others through http or RMI or some other
suitable method.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=530151715-07012004></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=530151715-07012004>Or is this one of
those magic moments where EJB actually would make sense?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=530151715-07012004></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=530151715-07012004>Regards Erik
Beijnoff</SPAN></FONT></DIV>
<DIV><FONT face=Arial
size=2></FONT> </DIV>=====================================================
======================
To unsubscribe, send email to listserv@(protected) and include in the body of
the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected) and include in the body of the message "help".
<P></P></DIV>
<DIV ALIGN="justify"> </DIV>
<DIV ALIGN="justify"><SPAN LANG="PT-BR" STYLE="FONT-SIZE: 10pt; COLOR: navy;
FONT-FAMILY: Arial; mso-bidi-font-family: KodchiangUPC"><SPAN LANG="PT-BR"
STYLE="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial; mso-bidi-font-family:
KodchiangUPC">this</SPAN><SPAN STYLE="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY
: Arial; mso-bidi-font-family: KodchiangUPC; mso-ansi-language: EN-US"> message<
/SPAN><SPAN LANG="PT-BR" STYLE="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial
; mso-bidi-font-family: KodchiangUPC"> contains information that may be
privileged and confidential. unauthorized use, disclosure, dissemination and/or
copying are strictly prohibited. if you are not the intended recipient, please
delete this message and any attachments and notify us immediately. please do
not copy this message or disclose its contents to anyone. thank you.</SPAN><
/SPAN></DIV>
<DIV ALIGN="justify"><SPAN LANG="PT-BR" STYLE="FONT-SIZE: 10pt; COLOR: navy;
FONT-FAMILY: Arial; mso-bidi-font-family: KodchiangUPC"><SPAN LANG="PT-BR"
STYLE="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial; mso-bidi-font-family:
KodchiangUPC"></SPAN></SPAN> </DIV></BODY></HTML>
===========================================================================
To unsubscribe, send email to listserv@(protected) and include in the body
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected) and include in the body of the message "help".
<p>
|
|
|
