Hi, Dennis! No need to subscribe to the dev list. We can handle the issue over JIRA:
https://issues.apache.org/jira/browse/TRANSACTION-16 Just add comments there. The code that I am referring to is in SVN in the TRANSACTION_2 branch. You can just use this link as a starting point: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/branches/TRANSACTION_2/src/java/org/apache/commons/transaction/ Note that this is work in progress and subject to many, many changes. OK. I would be more than glad to see you invest some time into this after your vavation :) Cheers Oliver 2007/7/15, Dennis Thrysøe <[EMAIL PROTECTED]>:
Oliver Zeigermann (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/TRANSACTION-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512556 > ] > > Oliver Zeigermann commented on TRANSACTION-16: > ---------------------------------------------- > > I have now tried to set up new landmarks for commons transaction 2.0. > All Java 5 features, including Generics and the concurrent package > are allowed now. > > Dennis, could you try and see where your work could fit in? > Especially, considering the new "internal" TransactionManager, > LockManager and LockPolicy. > > Does this make sense to you in the first place? Hi, Note that I am not on the mailing list for the time being. Too much traffic, and not much of relavance to me. I am unsure where I can read about the stuff you are referring to above. The wiki contains some notes from the 27th of june on version 2.0 - is that it? Therefore I'm not sure about the internal mechanisms you refer to. But, 1) Regarding locking, I'm hoping to implement MVCC support to avoid locking per se. Otherwise I would probably make much sense to use the already existing locking functionality in my implementations. 2) If you mean a TransactionManager as the term is used in JTA, I haven't implemented such a beast. I have a dummy/mock for testing purposes, that's all. Besides from the above I was considering moving all of my implementations into a single unified one for all kinds of objects. Since the "transactional object model" is based on recording method invocations, it could just as well be used for collections etc. The "depth" of recorded invocations could be declarable (for instance so only interface-method-invocations are recorded for collections. The problem with this is that any optimizations possible from the knowledge of the interface in question, are lost. If Java 6 and "our" dedicated class loader (or compile-time enhancing) could be assumed, the implementation could go to the ultimate level of transparancy with bytecode instrumentation that intercepts all field reads and writes. A whole area that I haven't put much thought into yet is distribution. I guess it's really a separate concern from isolation and transaction protection though. I'm on vacation these couple of weeks, but I'll see if I can put a bit of effort into this afterwards. -dennis --------------------------------------------------------------------------- The information in this email is confidential and may be legally protected. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
