commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juozas Baliuka <>
Subject RE: [simplestore] enhancements (was: [simplestore] inital check in)
Date Fri, 18 Jan 2002 08:46:35 GMT
simplestore is not the best optimization for projects like Cocoon.
You don't need it here. You don't need JISP and  StoreJanitor.
It kind of abstraction, but forget it if you need performance and want to 
save resources.
There are a lot of better ways to solve this problem.

1. Intercept request for HTTP Headers "Send IF Not Modified".
  You can cache some content on client side.
2. Don't use single file for cache. Map URL to file and store "large" 
content in file OS will do all this MRU stuf and cache for file system.
3. Don't write content to file if it is "small" store it in memory,
  you will have statistics on next request, and here you can decide what 
"large", "small","old","new","fast","slow".
4. Don't use any background cleanup, delegate all resource  management 
stuff for OS,JVM,GC where possible.

I don't know Cocoons code, it is possible there are more solutions and 
believe you will find them.

I believe we will make simplestore to be a good and abstact, but it is not 
solution for all cases, it can become
too "abstact" and it will be not "simple". It too simple for store and too 
complex for optimizations.
You can forward my emails for Cocoon developers, I believe they will 
understand me and this will help for you.
Cocoon seems very good framework for me, but I am not going to use it in 
any of my projects at this time, there are a lot of work to do.

At 11:44 PM 1/17/2002 +0100, you wrote:
> >From: Aaron Smuts []
> >
> >> -----Original Message-----
> >> From: Juozas Baliuka []
> >> Sent: Thursday, January 17, 2002 8:17 AM
> >> To: Jakarta Commons Developers List
> >> Subject: RE: [simplestore] enhancements (was: [simplestore] inital check
> >> in)
> >>
> >>
> >> >Maybe I understand you wrong, but look at this:
> >> >In the Cocoon project we have 2 stores a) MRUMemoryStore for quick access
> >> >and b) JispFilesystemStore for -well- swapping. Why? Because we
> >> store/cache
> >> >generated data (xml -> xslt -> html or fop or ...) in the cache.
> >> Generating
> >> >this data is very expensive.
> >>
> >>
> >>
> >> Ok, but it is not memory management, it is optimization for generation.
> >
> >It is reference management.
>I think we have definition problem here. I don't wanna re-build the memory
>management of the JVM. I just wanna provide some _small_, _quick_ and _ease_
>to plug components where people can store -well- *things*. Like in the Cocoon
>project generated HTML or PDF files to spare System resources, or a 
>Server which pools Objects, or whatever. Object in and throw Object out.
>The memory management of the JVM is doing the rest.
>We have to consider how we can use the JVM memory management and the GC in an
>most perfect way. Solution a) was the StoreJanitor which derefences 
>Objects and
>forces the GC after that or solution b) WeakReferences which seem to be a very
>elegant solution. I'm open for everything!
>That's the picture I have. What's yours?
>   Gerhard
>You can't fall off the floor
>To unsubscribe, e-mail:   <>
>For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message