RE: [Hibernate] Re: Hibernate and JCS Questions

[Gavin King <Ga...@expert.com>]

Oh .... I hadn't realized that the original message was so 
widely cross-posted.

I answered the original post more completely on the Hibernate
list, but I should also just confirm James' speculation that 
the reason we don't support use of JCS distributed caching with 
Hibernate is that we are extra fussy about ensuring transaction 
isolation and that implies some kind of locking of cached data.

Note that Hibernate has a pluggable cache architecture so it
is actually possible to plug in a caching strategy that has
weaker consistency guarantees than those assumed by Hibernate's
built-in strategies.

Gavin King
http://hibernate.sourceforge.net


> -----Original Message-----
> From: James Taylor [mailto:james@jamestaylor.org] 
> Sent: Thursday, 5 December 2002 1:56 PM
> To: Turbine JCS Users List
> Cc: 'hibernate-devel@lists.sourceforge.net'; Blair Harrison; 
> Tatum Lade; Lee Parayno
> Subject: [Hibernate] Re: Hibernate and JCS Questions
> 
> 
> > 1) How mature is JCS? Who is using it? On how many machines? With 
> > which of the three major configurations (fully distributed, 
> > client/server, client/cluster)?
> 
> I am using it. Two machines, memory caches on each. Put only 
> lateral distribution between them with javagroups. Quite basic really.
> 
> Others? (I'm curious too)
> 
> > 2) What was the process by which Gavin gained sufficient 
> confidence in 
> > JCS to include it in Hibernate?
> > 
> > 3) Why does Gavin indicate that JCS can't be used in a clustered 
> > read-write environment, in contradiction to the JCS documentation?
> 
> I suspect the biggest problem is that there is no distributed 
> locking, for JCS, which makes it difficult to use for O/R 
> mapping. In my case, we cache immutable read mostly data 
> objects, and when the underlying data store is updated for an 
> entity, it is purged from the cache. 
> 
> For more mutable data, I do not cache.
> 
> > 4) If we were able to commit to using Hibernate in a 
> read-only fashion 
> > and doing our data writing some other way, changing the 
> data out from 
> > under Hibernate, which various legacy admin tools will do 
> anyway, does 
> > this change the preference profile between Hibernate's 
> session-level 
> > cache vs. JCS? If so, how?
> > 
> > The bottom line, quite frankly, is that we're nervous about 
> relying on 
> > JCS in the absence of some reassurances about its maturity 
> and use in 
> > the real world, as JCS is clearly attempting to solve difficult 
> > engineering issues,
> 
> I wouldn't call JCS mature, but it works reasonably well for 
> some peoples needs, and is a good place to start for a 
> distributed cache. But because it has no consistency 
> guarantee between nodes in the cache, I'm not sure it is 
> workable for O/R mapping and multiple nodes.
> 
> (However, I believe one could implement an auxilliary which 
> provided more consistency -- all the hooks should be there)
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Microsoft Visual Studio.NET 
> comprehensive development tool, built to increase your 
> productivity. Try a free online hosted session at: 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
_______________________________________________
hibernate-devel mailing list hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel


********** CAUTION - Disclaimer **********
This message may contain privileged and confidential
information. If you are not the intended recipient of this
message (or responsible for delivery of the message to
such person) you are hereby notified that any use,
dissemination, distribution or reproduction of this message
is prohibited. If you have received this message in error,
you should destroy it and kindly notify the sender by reply
e-mail. Please advise immediately if you or your employer
do not consent to Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this
message that do not relate to the official business of
Expert Information Services Pty Ltd ("The Company")
shall be understood as neither given nor endorsed by it.

The Company advises that this e-mail and any attached
files should be scanned to detect viruses. The Company
accepts no liability for loss or damage (whether caused
by negligence or not) resulting from the use of any
attached files.
**EIS******** End of Disclaimer **********