On 16 Nov 2004, at 22:03, Oliver Zeigermann wrote:
I think your request is very reasonable. However, this really is an integrated component. Both the file system and the maps rely on the locks. Compare this to e.g.
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ intro.html
where you have a similar structure for more general concurrent Java programming. You have locks that are used by the channels and the collections and some more general purpuse helpers. You would not split this to more than one package, would you?
we've found in the commons that tight, focussed components have done best :)
thinking about scope before promotion and writing it down saves arguments later. (it's also part of the charter.)
Now, the transaction component aims at the same thing as the concurrent package, but is specific to transactions.
that makes sense.
so (for example) like doug lea's original, transaction (probably) aims to be lightweight with minimal dependencies, and provides well tested, rigourous solutions for the most common use transactional use cases. (i have no doubt that you'll probably come up with something a lot better...) that way, in years to come when oddballs propose some heavyweight solution with big dependencies for an obscure problem, you'll be able to points them straight to your scope, saving weeks of argument :)
You are very right and this really should be made explicite, thus I will add this as a scope to the index page of the transaction component ASAP.
May a presume that this changes your vote to +1?
come up with a good scope, discuss (as necessary) with the transaction community then commit and i'll cast a new vote :)
(you'll thank me in the long run for insisting that you don't rush ;)
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
