cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bart Molenkamp" <b.molenk...@bizzdesign.nl>
Subject RE: Identifier used in FragmentExtractorTransformer
Date Tue, 25 Oct 2005 07:06:09 GMT
Hi,

> -----Oorspronkelijk bericht-----
> Van: Joerg Heinicke [mailto:joerg.heinicke@gmx.de]
> > So what is your solution? I can't find it in the mail archive...
> 
> They are added as comments to the bug which can now be found at Jira:
> http://issues.apache.org/jira/browse/COCOON-1148
> 
> Jörg
> 

(Can it be discussed here, or do I need to add them as comments to the issue too?)

I don't totally agree with your latest comment. The CacheValidity won't solve the problem,
IMO it's a problem with the ID being generated that is not unique. In my case, the URI for
a report is always the same, but the contents of that report is based on who is calling it.
Multiple users can call the same URI, each resulting in different content. Suppose:

1. User A requests the report, fragment A is extracted.
2. User B requests the report, fragment B is extracted, and overwrites A because it has the
same ID.
3. User A requests the fragment, but gets fragment from user B.
4. User B requests the fragment, and gets his fragment B.

A cache validity won't solve this, there is just a need to store multiple fragments in the
same store. With a CacheValidity, the following could still happen:

User A can request the report, fragment A extracted
User B can request the report, report B doesn't have the same validity as report A, so the
fragment is replaced.
User A requests fragment A, but gets fragment B.
User B requests fragment B, and gets fragment B.

Besides that I think that caching is done at the pipeline level: if the generator, transformers
and the serializer indicate that the cache is valid, then the cached content will be returned
and in that content of course the link to the extracted fragment - but the fragment isn't
extracted again.

So I think that it is just as simple as to generate an unique ID. Maybe some UUID, maybe something
with a SecureRandom (like how continuation IDs are generated). Also, I suggested to move this
ID generation to a protected method, so that users can override that method in the transformer
and implement their own method to generate an ID (won't break the current way that the extractor
is working).

Am I correct on this?

Thanks,
Bart.


Mime
View raw message