commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Zeigermann <>
Subject Re: [transaction] Paths for IDs, and locking
Date Thu, 11 Nov 2004 17:06:13 GMT
Hi Antranig,

thanks again for your feedback!

On Thu, 11 Nov 2004 14:08:59 +0000, Antranig Basman
<> wrote:
> Thanks - I will proceed to use FRM in all confidence :)

I guess you can...

> 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.

Fine, looking forward to this :) If you have more need to discuss a
possible solution, please do so on this list...

> Another question - I'm looking over the locking strategy for FRM
> and am keen that I can ensure it blocks rather than throwing

Yes, serializability (complicated word, hope the spelling is right) is
guaranteed by locks. There are four lock level
0: none
1: request wide read outside of transactions
2: transaction wide read (shared)
3: transaction wide write (exclusive)
4: commit lock that prohibits all other locks on resources being committed

However, if a lock can not be acquired in the specified time the lock
methods will throw exceptions. Currently, the file system can not tell
a livelock from a deadlock. Both will just throw an exception...

> 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?

Yes, or if it has explicitely been marked for roll back by method
markTransactionForRollback. The reason is to tell the user not to make
any modifications to a transaction that will eventually fail anyway.
However, you are right, this is not mandatory for correctness...

> 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.

Do not quite understand this. Could you explain a bit more, please?

Note that it is still possible to actively set a transaction to rollback only.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message