Hi, > -----Oorspronkelijk bericht----- > Van: Joerg Heinicke [mailto:[EMAIL PROTECTED] > > 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.
