commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [transaction] splitting ResourceManager interface
Date Sat, 15 Jul 2006 11:43:41 GMT
Oliver Zeigermann <oliver.zeigermann <at>> writes:

> That certainly is post 1.2, right? Maybe even some work for a 2.0
> version?

Yes, definitely after the current release process. We can decide whether it gets
1.3 or 2.0 or what else, when we have the code :)

> Hmmm. Why do you need FileResourceManagers in the fist place? Just to
> synchronize file access? Not quite sure here...

Not that much synchronizing, but more the transactional behaviour. The
FileResourceManager in my use case also takes part in global transactions. You
remember my work on the XA stuff at the beginning?

(OT: Sometimes ago I mentioned that this XAResource implementation might be
donated to Commons Transaction. I got no go from my employer at that time. We
were taken over by another company and our management did not want to decide
about those things. Maybe I should put it back on the table ...)

> Anyway, TransactionManager wouldn't be such a good name for a new
> class as it has a predefinied meaning in the J2EE world I guess.

Ok, naming clashes might better be avoided. But from the meaning I chose the
name after comparing with the JTA TransactionManager interface as the
ResourceManager's methods related to transaction handling and the JTA
TransactionManager methods are quite similar. So I don't think there is a
different meaning. And how many ResourceManagers exist in the world? ;)

> One way would be to leave the ResourceManager interface untouched and
> introduce your two new interfaces. FileResourceManager would implement
> all three interfaces.

Yes, of course ... good idea ...

> Another idea would be to make it all better in 2.0 and do not care too
> much for backward compatibility. One idea might be to even use Java 5
> locking. Maybe this is stuff for another thread, though...

I don't want to change that much at the moment. Just splitting the concerns with
care for backward compatibility.

About Java 5: I have never used it yet. Don't know what it can really buy us
though I read much about its nice features.
But let's do one step after another ;)


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

View raw message