Joerg Heinicke wrote:
On 19.05.2004 13:02, Carsten Ziegeler wrote:
Before this week we had a non-working persistent store, now we have no longer a persistent store, but a two-stage caching system with both JCS and EHCache? What about the Serializable issues?
Ok, let me try it:
- Between 2.1.4 and 2.1.5 we had the refactoring of the stores. The basic
idea is to have only two stores that should be used by clients:
the store and the transient store. The transient store is - well -
transient - it does not persist data. The store should also persist
data. It should implement a two phase store (memory -> disk).
- The old (jisp) based implementation of the store used the persistent
store to persist the data.
- Due to the refactoring we had severe problems (don't know which)
that prevented us from releasing - this came up on friday. (it was
mentioned here and there earlier)
That was Sylvain's refactoring IIRC.
Yep. And this refactoring made JISP bugs apparent since on-disk data was never retrieved before (even if written)
- Now: we are using JCS for the store. JCS itself has a two-phase caching implemented and therefore we don't need a persistent store anymore.
But the second phase is not intended as persistent store, is it?
Since JCS does both memory front-end + disk back-end, it can be _the_ store, and we no more need the persistent store.
- We still use the memory store for the transient store.
How do JCS phase I and MRUMemoryStore play together here - or do I mix two different things?
They live their lives on their own, orchestrated by the store janitor.
- If you put objects into the store, they have to be serializable now. Even if JCS holds the data just in memory, it assumes that the objects are serializable. Perhaps they will change this perhaps not.
What about the non-Serializable objects? Logicsheets and Paginator stuff were mentioned. Are these objects not put into transient store?
Yep. And the transient store does not (and should not) require objects to be serializable (that's its main purpose compared to the regular store that may persist objects).
Although this is different from the jisp based version it doesn't affect us as we are using serializable objects anyway - which makes sense as they whole data should be persistent later on.
- If you put objects into the transient store they don't have to be serializable.
- Persisting cache entries inbetween application starts didn't work very well with Jisp as we had bugs in Cocoon. This works now with JCS. - There is only one bug: JCS is not always writing the data to disk. It seems that there has to be a critical mass of data before it gets written. - we reported this issue and I hope they will fix it. But this is not a serious issue as the persistence is not that important and didn't work before anyway.
So, to sum it up: imho we have no a working system that is based on JCS.
I get the feeling that JCS is not used for transient store (but MRUMemoryStore), so no JCS phase I. And JCS phase II (now replacement for old Jisp persistent store) has minor bugs as written above.
IIUC the main store based on JCS uses the two phases (memory + disk), and it seems we can live for now with the minor shutdown bug.
There are minor problems that we can fix in the next releases.
I don't want to block the release, you get my +1. I'm just curious and want to know how the stuff is working now - and if I can use the release in a project of course.
+1 from me also.
You guys did an amazing job to solve this issue. I lacked time to participate, being very busy on a project. The good news however is that this will lead to interesting new CForm features :-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
