[EMAIL PROTECTED] wrote:
-----Original Message----- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 17:20 To: Slide Developers Mailing List Subject: Re: How about RC1?
OK, I see now and am convinced. The patch proposed by Martin to use /history/1/2/h3 instead of /history/123 is nice to reduce the number of resources in a folder anyway, right?
Yes, it is. I haven't seen the patch in detail. I think we have to be careful with parts of the code, where an URI is analyzed to determine whether it belongs to a history or a version. Probably, currently ${historypath}/xxx would be taken for a history URI, ${historypath}/xxx/yyy would taken for a version URI, and ${historypath}/xxx/yyy/zzz would be rejected as invalid.
In Martins patch /history, /history/1, /history/1/2, etc. are history URIs and /history/h1, /history/1/h1, /history/1/2/h1 are version URIs I guess. I understand your reservation, but on the other hand Martins solution takes of the performance problem.
What should we do?
Maybe, an init-parameter "generateBalancedHistoryURIs" (or the like) in web.xml to be able to switch-off or customize the new behaviour would be nice? Comments?
This sounds like a good idea. Martin, do you agree?
What would be a more appropriate fix to bug #26913? Having sequences would require API changes for the store and are thus impopssible for the 2.0...
We, at Software AG, probably didn't detect this problem because the Tamino store uses its own t-locking (and StandardStore is used instead of ExtendedStore as parent store) and it didn't occur with that. My guess is that we just have to ensure that the resource at ${historypath} (i.e. the folder /history in Slide's default config), which carries the property "next-history-name" (Nsp="http://jakarta.apache.org/slide/";) for the generation of the next history URI, is appropriatly locked. Isn't that given if the Slide-Token has been setForceStoreEnlistment(true)?
I am wondering why the underlying store (same thing with file and db store) does not do the locking we want for us. Maybe I have to dig a bit deeper...
OK. Fixed all this, was a combination of caching not propagating locks to the physical stores and locks for updating the history counter not being strict enough.
I would like to check this in to UriHandler now, but do not know which version to take. Shall I revert Martin's changes?
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
