commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antranig Basman <>
Subject [transaction] Paths for IDs, and locking
Date Thu, 11 Nov 2004 14:08:59 GMT
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
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
> (
> and send the answer to my message to
> 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:
For additional commands, e-mail:

View raw message