commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Klaasen (TeleRelay)" <tom.klaa...@telerelay.com>
Subject RE: [simplestore] inital check in
Date Wed, 16 Jan 2002 10:13:14 GMT
I'm still not sure I'm completely up to speed with you...

> -----Original Message-----
> From: Juozas Baliuka [mailto:baliuka@mwm.lt] 
> Sent: woensdag 16 januari 2002 11:11
> To: Jakarta Commons Developers List
> Subject: RE: [simplestore] inital check in
> 
> 
> 
> >A Cache should not be responsible for storing, should it? 
> Then it isn't
> >a cache, but a DB...
> 
> I recommend to use some Storage interface for cache. You will 
> be very glad
> then you will decide at later time to store your applications 
> state to 
> stable Storage, add transactions .... .

I don't think this should be the responsibility of the cache. There
could be another mechanism that does this, which is linked to the Cache
in some way. But the cache itself only knows about memory and objects,
not about persistency.
 
> >And even if you're going to do this, make a clean separation 
> between the
> >cache and the persistency layer (do not assume it is a 
> database. It can
> >be a filesystem, or a WebDAV system, or a Jisp system, ...)
> 
> I thing about cache as special kind of "persistency layer".

Yes, which is a layer above the other layers. I agree with that. But you
cannot assume the underlying layer is a DB. In my case, the underlying
layer is a class that connects to a DB and retrieves XML via stored
procedures. The API is very proprietary.
I think the point I want to make is this: abstractize the underlying
layer. Make it an interface which can be implemented for DB, for
filesystem, etc etc (hey -- even setup(Properties props) could be an
idea to make the interface as general as possible)

> >I'm not even sure what you're going to do with this stored 
> procedure...
> It can be any kind interface for finders (EJB QL, JDO 
> QL,SQL,OQL, My QL , 
> Some API,....).
>   procedures are more useful for updates .
> 
> procName.1={call some_proc(?)}
> procName.2=SELECT something  .... WHERE ID=?
> procName.3=MyClass.someStaticMethod(1)
> procName.4=protocol://www.something.com?id={0}
> 1=ProcDescriptorClass1
> 2=ProcDescriptorClass2
> .................................................
> procName.descriptor=x
> 
>   DB.call("procName", new Object{new Integer(0)});
> May  be it is not the best idea, but it works good for me.

Jep, and I do the same in my app, but a layer lower (_not_ in the cache,
but in the DB layer, which is the persistency layer I described above).


> >Just giving my opinion, as I'm looking for a decent cache 
> for some time
> >now and I'm considering using simplestore.
> I can recomend a very special kind of cache "OS Cashe": 
> http://www.opensymphony.com
> If you use JSP in youe application.

Thanks for the tip, I should look into this -- but that is the other
side (front-end) of the app, while I'm looking for a cache for the
back-end (persistency layer).

tomK

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message