Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <40AB511E.4010409@apache.org>
Date: Wed, 19 May 2004 14:20:46 +0200
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [VOTE] Release on monday
References: <OF956AA0F9.8178C6A3-ONC1256E99.003BE82A@sundn.de>
 <40AB458A.1020000@gmx.de>
In-Reply-To: <40AB458A.1020000@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 }