 | 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-09 - By Erik Beijnoff
Back
Ok. Nice to hear another opinion. It's always good to get another view
on things.
My problem in short was how to keep caches living on separate machines
in synch with each other, when the underlying data (database) may be
changed without the caches being aware of it. The response was mostly to
redesign my implementation to use Entity Beans with a Facade that I
communicated with that in turned had single access to the database.
I myself had an idea of letting the caches register themselves in a
single location, and then handle invalidation requests from the updating
application server through HTTP or RMI whenever any of the application
servers updates the database.
I'm not sure how I will handle it, the implementation is a month or two
away, so I'll think about it until then. What you describe may be
applicable. We'll see.
Regards Erik Beijnoff
-- --Ursprungligt meddelande-- --
Fr�n: A mailing list for Java(tm) 2 Platform, Enterprise Edition
[mailto:J2EE-INTEREST@(protected)] F�r Steven Warren
Skickat: den 8 januari 2004 18:47
Till: J2EE-INTEREST@(protected)
�mne: Re: Shared cache best practices?
Entity beans are not really a good solution for any situation and I
think should be culled from the herd of J2EE. I don't recommend you go
down that path as it will not likely give you good performance,
scalability, or reduced complexity. I have a large CMP Entity Bean
application (luckily successful) and I am warning you away from this
approach.
I didn't really hear enough about your situation to suggest a good
caching mechanism. The approach I took was to front my EJB calls with a
wrapper who returns cached data if the data has not been invalidated,
when data is posted, objects in the cache are invalidated via a
notification to each invalidated cached object (objects register to be
notified when they are put in the cache). But again, I don't know if
this is applicable to your situation.
Regards
Steve
-- --Original Message-- --
From: A mailing list for Java(tm) 2 Platform, Enterprise Edition
[mailto:J2EE-INTEREST@(protected)] On Behalf Of Erik Beijnoff
Sent: Thursday, January 08, 2004 12:38 AM
To: J2EE-INTEREST@(protected)
Subject: Re: Shared cache best practices?
Thanks for the responses. You've been verry helpful. I've gotten some
alternative approaches to think of it, and those of you who have
answered seems to lean towards the Entity Beans approach.
> Depending on your container, you may get automatic invalidation for
free -
> by using the appropriate "commit option" (without needing JMS).
> This is all assuming that all modifications to the tables that have
the cached data are being done through entity beans.
> In any event, it seems entity beans would be a good fit. You will need
to decide whether to
> keep your strategy of separate caches per web server (which will mean
an app server local to each web server).
For the moment I am not using Entity Beans or EJB. Just a domain model
made out of Pojos manipulated through a DB Peer, so it's really not an
app server for each web server, rather several web server with caches.
If I where to use Entity Beans, do they make a good joob replicating
over several servers, or can I expect the app server holding the Entity
Beans to become a bottleneck in the future?
Best 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) and include in the body of the message
"help".
========================================================================
=== 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".
===========================================================================
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".
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:eXclaimer = "http://www.exclaimer.co.uk" xmlns:o =
"urn:schemas-microsoft-com:office:office"><HEAD><TITLE>Meddelande</TITLE>
<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.1276" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=207273114-09012004><FONT face=Arial color=#0000ff size=2>Ok.
Nice to hear another opinion. It's always good to get another view on
things.</FONT></SPAN></DIV>
<DIV><SPAN class=207273114-09012004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=207273114-09012004><FONT face=Arial color=#0000ff size=2>My
problem in short was how to keep caches living on separate machines in synch
with each other, when the underlying data (database) may be changed without the
caches being aware of it. The response was mostly to redesign my implementation
to use Entity Beans with a Facade that I communicated with that in turned had
single access to the database.</FONT></SPAN></DIV>
<DIV><SPAN class=207273114-09012004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=207273114-09012004><FONT face=Arial color=#0000ff size=2>I
myself had an idea of letting the caches register themselves in a single
location, and then handle invalidation requests from the updating application
server through HTTP or RMI whenever any of the application servers updates
the database.</FONT></SPAN></DIV>
<DIV><SPAN class=207273114-09012004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=207273114-09012004><FONT face=Arial color=#0000ff size=2>I'm
not sure how I will handle it, the implementation is a month or two away, so
I'll think about it until then. What you describe may be applicable. We'll
see.</FONT></SPAN></DIV>
<DIV><SPAN class=207273114-09012004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=207273114-09012004><FONT face=Arial color=#0000ff
size=2>Regards Erik Beijnoff</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=sv dir=ltr align=left><FONT face=Tahoma
size=2>-- --Ursprungligt meddelande-- --<BR><B>Fr�n:</B> A mailing list for
Java(tm) 2 Platform, Enterprise Edition [mailto:J2EE-INTEREST@(protected)]
<B>F�r </B>Steven Warren<BR><B>Skickat:</B> den 8 januari 2004
18:47<BR><B>Till:</B> J2EE-INTEREST@(protected)<BR><B>�mne:</B> Re: Shared
cache best practices?<BR><BR></FONT></DIV>
<DIV><SPAN class=589413517-08012004><FONT face=Arial color=#0000ff
size=2>Entity beans are not really a good solution for any situation and I
think should be culled from the herd of J2EE. I don't recommend you go down
that path as it will not likely give you good performance, scalability, or
reduced complexity. I have a large CMP Entity Bean application (luckily
successful) and I am warning you away from this approach.</FONT></SPAN></DIV>
<DIV><SPAN class=589413517-08012004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=589413517-08012004><FONT face=Arial color=#0000ff size=2>I
didn't really hear enough about your situation to suggest a good caching
mechanism. The approach I took was to front my EJB calls with a wrapper who
returns cached data if the data has not been invalidated, when data is posted
,
objects in the cache are invalidated via a notification to each
invalidated cached object (objects register to be notified when they are put
in the cache). But again, I don't know if this is applicable to your
situation.</FONT></SPAN></DIV>
<DIV><SPAN class=589413517-08012004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=589413517-08012004><FONT face=Arial color=#0000ff
size=2>Regards</FONT></SPAN></DIV>
<DIV><SPAN class=589413517-08012004><FONT face=Arial color=#0000ff
size=2>Steve</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-- --Original Message-- --<BR><B>From:</B> A mailing
list
for Java(tm) 2 Platform, Enterprise Edition
[mailto:J2EE-INTEREST@(protected)] <B>On Behalf Of </B>Erik
Beijnoff<BR><B>Sent:</B> Thursday, January 08, 2004 12:38 AM<BR><B>To:</B>
J2EE-INTEREST@(protected)<BR><B>Subject:</B> Re: Shared cache best
practices?<BR><BR></FONT></DIV>
<DIV><SPAN class=722522316-07012004><FONT face="Lucida Sans Unicode"><FONT
size=2><SPAN class=646363008-08012004><FONT face=Arial>Thanks for the
responses. You've been verry helpful. I've gotten some alternative
approaches to think of it, and those of you who have answered seems to lean
towards the Entity Beans approach.</FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=722522316-07012004><FONT face="Lucida Sans Unicode"><FONT
color=#0000ff><FONT size=2><SPAN class=646363008-08012004><FONT
face=Arial></FONT></SPAN></FONT></FONT></FONT></SPAN> </DIV>
<DIV><SPAN class=722522316-07012004><FONT face="Lucida Sans Unicode"><FONT
color=#0000ff><FONT size=2><SPAN class=646363008-08012004><FONT
face=Arial>> </FONT></SPAN>Depending on your container, you may get
automatic invalidation for free - <SPAN class=646363008-08012004><FONT
face=Arial> </FONT></SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=722522316-07012004><FONT face="Lucida Sans Unicode"><FONT
size=+0><FONT color=#0000ff><FONT size=2><SPAN
class=646363008-08012004><FONT face=Arial>></FONT> </SPAN>by using
the appropriate "commit option" (without needing JMS). <SPAN
class=646363008-08012004><FONT
face=Arial> </FONT></SPAN></FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=722522316-07012004><FONT face="Lucida Sans Unicode"><FONT
size=+0><FONT size=+0><FONT color=#0000ff><FONT size=2><SPAN
class=646363008-08012004><FONT face=Arial>></FONT> </SPAN>This is
all assuming that all modifications to the tables that have the cached data
are being done through entity beans.<SPAN class=646363008-08012004><FONT
face=Arial> </FONT></SPAN></FONT></FONT></FONT></FONT></FONT></SPAN><
/DIV>
<DIV><SPAN class=722522316-07012004><FONT face="Lucida Sans Unicode"><FONT
size=+0><FONT size=+0><FONT color=#0000ff><FONT size=2><SPAN
class=646363008-08012004><SPAN class=722522316-07012004><FONT
face="Lucida Sans Unicode" color=#0000ff size=2>> In any event, it seems
entity beans would be a good fit. You will need to decide whether to
</FONT></SPAN></SPAN></FONT></FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=722522316-07012004><FONT face="Lucida Sans Unicode"><FONT
size=+0><FONT size=+0><FONT color=#0000ff><FONT size=2><SPAN
class=646363008-08012004><SPAN class=722522316-07012004><FONT
face="Lucida Sans Unicode" color=#0000ff size=2>> keep your strategy of
separate caches per web server (which will mean an app server local to each
web
server).</FONT></SPAN></SPAN></FONT></FONT></FONT></FONT></FONT></SPAN><
/DIV>
<DIV><SPAN class=722522316-07012004><FONT face="Lucida Sans Unicode"><FONT
size=+0><FONT size=+0><FONT color=#0000ff><FONT size=2><SPAN
class=646363008-08012004></SPAN></FONT></FONT></FONT></FONT></FONT></SPAN>
</DIV>
<DIV><SPAN class=722522316-07012004><FONT face="Lucida Sans Unicode"><FONT
size=+0><FONT size=+0><FONT size=2><SPAN class=646363008-08012004><FONT
face=Arial>For the moment I am not using Entity Beans or EJB.
Just a domain model made out of Pojos manipulated through a DB
Peer, so it's really not an app server for each web server, rather several
web server with caches. If I where to use Entity Beans, do they make a
good joob replicating over several servers, or can I expect the app server
holding the Entity Beans to become a bottleneck in the
future?</FONT></SPAN></FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=722522316-07012004><FONT face="Lucida Sans Unicode"><FONT
size=+0><FONT size=+0><FONT face=Arial size=2><SPAN
class=646363008-08012004></SPAN></FONT></FONT></FONT></FONT></SPAN> <
/DIV>
<DIV><SPAN class=722522316-07012004><FONT face="Lucida Sans Unicode"><FONT
size=+0><FONT size=+0><FONT face=Arial size=2><SPAN
class=646363008-08012004>Best regards Erik
Beijnoff</SPAN></FONT></FONT></FONT></FONT></SPAN></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></BLOCKQUOTE>=======================================================
====================
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></BLOCKQUOTE></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>
|
|
|
