commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antranig Basman <antra...@caret.cam.ac.uk>
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
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 commons-user@jakarta.apache.org
> 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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message