Sorry for the late answer, but Friday was a public holiday in France... :)
On 15/08/2003 02:34, Geoff Howard wrote:
Olivier Billard wrote:
Cool !
Thanks for your answer, it conforts me in my choice : I think I'll use database mapping with maybe a custom MRU cache. But I'm afraid of the time to reinstanciate objects from the database...
If you will be storing whole objects you could give it a try I guess.
You meant a try to the cocoon store, I guess ?
Just watch out for the cache clearing I mentioned before. Currently the clear persistent store action (and the 2.1 event-based cache under some circumstances) are the only things that should do this, so it may not be a problem in your particular situation.
I think an independant store (reusing cocoon or excalibur components or not) would be better for me due to these uncontrolable possible actions ...
PS : It reminds me that the excalibur cache component seems to be dead...
This should be clarified a little. There is I think an excalibur Cache project that I don't know anything about.
The cache is still on their online API, but no more on the CVS...
But Cocoon's Cache is just a thin wrapper around the Excalibur Store project which we do use and is not dead. It started out in Cocoon's cvs but moved to excalibur because it was judged to have general usefulness. Not sure if this change was in effect at 2.0.4 or not.
... that did the excalibur cache component ?
-- Olivier
Geoff
On 14/08/2003 12:49, Geoff Howard wrote:
Olivier Billard wrote:
Hi Geoff,
I'm using a modified version of the workflow component of the krysalis project.
I want to store persistently states of this workflow, these states could bo modelized as beans (java objects with attributes to be precise). These objects could be numerous (a thousand ?). I'm looking for the best manner to store these objects :
- database mapping (the best solution I think) with light memory store (caching ? complete light model ?)
- excalibur store (filesystem access = overload ?)
And I'm wondering if the store defined in the cocoon.xconf is ready to use for client app or if it is already used by Cocoon components...
I hope I'm clear ;)
You are clear. I'd advise you toward the database mapping. There are
examples popping up of using tools like Hibernate to abstract that if you like, or you can use straight jdbc.
The Store you see in cocoon.xconf is used internally by Cocoon for caching pipeline results and parsed transformers, etc. While you can use it for application storage I'd recommend against it - I don't know of anyone else who has used it that way (if you're out there and have, speak up and let us know how it worked). I could give more info on why I'd recommend against if you need it.
Geoff
On 13/08/2003 23:27, Geoff Howard wrote:
Olivier Billard wrote:
Hi all,
I would like to use store components for persistent storage.
Why?
Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
