Thanks - I will proceed to use FRM in all confidence :) Yes, I could provide a patch for this, although expanding the filesystem limit will not fall onto my development path until my app gets close to deploying. Perhaps a week or two, all going well.
Another question - I'm looking over the locking strategy for FRM and am keen that I can ensure it blocks rather than throwing whenever possible. I notice that in lockResource() there is a call to assureNotMarkedForRollback(context); which, by my best understanding, will throw if a prepareTransaction has failed on the resource. Could you explain why this is necessary? To be sure, if one transaction has failed on modifying a resource, it is quite likely that another will, and the time window for observing this effect is only that between a prepare fail and an exception handler being located for a rollback, but I'd like to understand the reasoning behind it if I can. Oliver Zeigermann wrote: > > Hi Antranig, > > thanks for the feedback :) > > Concerning status: all parts of the code are currently used in the > Jakarta Slide project and seem to work very well. The default > implementation of a file store is based on the FileResourceManager and > no errors have been reported for more than half a year. So this seems > to be stable. However, as you noticed yourself, the code could be more > generic. That's why I appreciate your input. > > Concerning your special issue: I guess overloading getMainPath should > work just fine. However, the PathForIDMapper could do the job for both > this and for the encoding of a resource to a path. I think this is a > very good idea. I suppose the idea of getAllPaths() is to know which > directories to create, right? > > What about the implementation, would you be able to provide a patch > for this? Anyway, for legal reasons - really, not kidding - all code > submissions, even your fragment below must be sent to public lists, > otherwise I can not accept them. So, I would kindly ask to continue > our discussion in the commons user list where the transaction package > resides. Please subscribe to the list > (http://jakarta.apache.org/commons/sandbox/transaction/mail-lists.html) > and send the answer to my message to [EMAIL PROTECTED] > and start the subject with [transaction]. > > Thanks, > > Oliver > > > Hi Oliver, thanks for your great work on this, it looks like a fine > > library. > > What is the status of the head CVS version - is it receiving > > reasonably thorough current use which might expose any problems? > > I am mainly using the FileResourceManager. > > I would like to have more control over the way in which IDs are > > mapped onto filenames, and in particular the ability to spread > > the main store over multiple directories, to avoid reaching maximum > > file count limits in popular poor filesystems such as FAT. > > I could do this by overriding the getMainPath method and some others, > > but this seems somewhat sleazy. I'd also like to get your > > opinion on any other invariants of the system that might be broken > > (apart from the requirement to ensure all subdirectories are already > > created at startup) should I start mapping to paths containing slashes > > in getMainPath. > > > > Use of an interface something like this could help - the > > Base64 decision for example seems something that should really be > > delegated to external code. > > > > public interface PathForIDMapper { > > /** Returns a path, possibly including a directory prefix > > statically * hashed from the supplied resource ID */ > > public String getPathForID(ResourceID id); > > /** Returns a list of all prefixes that could possibly be returned > > * by getPathForID */ > > public String[] getAllPaths(); > > } > > > > Thanks, > > Antranig. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
