jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Travis Savo <ts...@IFILM.com>
Subject RE: Moving forward with JCS
Date Mon, 05 Apr 2004 19:34:04 GMT
After reading a bit more about it I realize that it's just a 'data-store'
and not a queryable relational database, so it's not as heavy handed as I
first expected it to be, and may be a very viable solution in certain
situations where JCS isn't appropriate.

-Travis Savo

-----Original Message-----
From: Travis Savo [mailto:tsavo@ifilm.com]
Sent: Monday, April 05, 2004 11:49 AM
To: 'Turbine JCS Users List'
Subject: RE: Moving forward with JCS


Seems pretty heavy handed for a replacement as a 'lightweight caching
architecture'. What you probably won't find (and this is after reading the 2
second blurb so please don't take my word for it) is the expiration and idle
code, so you'd have to write that your self (no biggie), and like you
mentioned no object replication.

Remember that at the heart of this it's going into an (admittedly very
lightweight) database, which is kinda a bit more of a beast than JCS. From
the article I gathered that it's basically sticking the objects being
persisted through serialization every time (but perhaps not) which JCS only
does on remoting operations. 

>From the blurb:

"Berkeley DB JE's architecture employs a log-based, no-overwrite storage
system, enabling high concurrency and speed while providing ACID
transactions and record-level locking. Berkeley DB JE efficiently caches
most commonly used data in memory, without exceeding application-specified
limits. The Berkeley DB JE architecture provides an underlying storage layer
for any Java application requiring high performance, transactional integrity
and recoverability."

So you can imagine this is probably a little bit more complicated than:

JCS.getInstance(region).put(key, value);
JCS.getInstance(region).get(key, value);
JCS.getInstance(region).remove(key, value);

...directly out of the box.

On the flip side, it would be amazing if this supported Object Oriented
Queries (like Hibernate), and if transactional integrity is a requirement
for your caching strategy, this might be an ideal solution.

Don't get me wrong... it looks like an amazing product. But it's an embedded
database, not a pluggable caching solution.

-Travis Savo


-----Original Message-----
From: Nguyen, Thod [mailto:TNguyen@corp.untd.com]
Sent: Monday, April 05, 2004 11:18 AM
To: 'Turbine JCS Users List'
Subject: RE: Moving forward with JCS


What is your guys take on the release of Berkeley DB for Java? 
It seems to do whatever JCS is doing without the data replication
support....

http://www.theserverside.com/news/thread.tss?thread_id=24926#116624

-----Original Message-----
From: Matthew Cooke [mailto:mpcooke3@lineone.net]
Sent: Saturday, April 03, 2004 12:41 PM
To: Turbine JCS Users List
Subject: Re: Moving forward with JCS


I've updated to Travis's new code and we are still start getting wrong 
values being returned for keys on some machines. It seems the problem 
only occurs after restarting some of the machines in the cluster.

The configuration we are using is 1 "builder" machine just doing put's 
and 2 serving machines just doing (a lot of) "get's" the builder is 
configured with 2 LTCP caches one to each serving machines. Each serving 
machines also has an LTCP cache connecting it to the builder.

The problem only seems to occur when you restart some of the machines. 
Then it appears somehow something get's out of sync in JCS and I reckon 
sometimes when you ask for an object for a certain "Put Key" you receive 
the value object for the previous get() request.

The Builder machine is configured with auxiliary caches DC, 
LTCP_Server1, LTCP_Server2
and each serving machine is configured with auxiliary caches DC, 
LTCP_Builder

This configuration does appear to work without error until you restart 
machines.

Firstly, does anyone know what could be causing this? Secondly does 
anyone else use the LTCP auxiliary with restarts under a heavy load?

Regards,
Matthew Cooke.


Travis Savo wrote:

>Just a little brainstorming... feel free to correct me if I'm off track
>here.
>
>Documents that are in desperate need of writing:
>Using Remote Cache: Step by step guide for using Remote Cache (because it's
>harder than it looks!), how it works, when to use it, and when it won't do
>what you expect it to. (I've already started on this one and expect to have
>it soon)
>Using Lateral Cache: Step by step guide for using Lateral Cache, how it
>works, and when to use it.
>
>What's still needed before I'd consider this 'stable and mature':
>Get my patches for LRU, Remote, Disk cache, and stastics gathering back
into
>CVS.
>Unit tests to test expiration, idle, and max objects with precision, and
>accompanying cache.ccf configurations.
>Unit tests for Remote Cache (tricky, but doable).
>Unit tests for Lateral Cache.
>Unit tests for the Read/Write locking semantics.
>More people to run the unit tests, and try it in new and interesting ways.
>(Please help!)
>Optional Disk Persistence over reboots via cache.ccf configuration (see
>prior posts for more info).
>
>Moving forward:
>The CacheEventQueues (and everywhere else this is done) should probably
stop
>using hand-rolled linked lists in favor of an FIFO buffer implementation a
>little more standard and less bug prone (commons-collections perhaps?).
This
>should help to clean up the code a bit.
>
>Comments? Questions? Screams of agony?
>
>If no one has any objections I'll be posting these things as I complete
>them, but anyone can feel free to jump in and tackle one of these, or
>suggest some others, or say why what I'm suggesting is a Bad Thing(tm).
>
>-Travis Savo
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org


.

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org


Mime
View raw message