Hello, I'd like to propose an addition to the Castor interface to assist in what I feel should be a relatively common need: developer transaction synchronization.
Basically, if you want to implement MFC, you need to propagate changes from the Model (persisted objects) out to various Views (Stateful Session Beans, for instance) when changes are made. However, changes aren't "real" and can't be safely propagated until the transaction has successfully committed. This implies that there is a great deal of interest in having user code know about and do things on based on transaction events. In the current API, there is no visibility into transaction events.... Hmmm... If there was only a way to get a callback... ;) The java.transaction.xa.Synchronization interface is the way this is done (and it's already the way JDO ties into an MTS). The proposed change (and implementation) is fairly simple: The JDO class and the Database interface each get two methods: public void setSynchronization(Synchronization aSynch); public Synchronization getSynchronization(); (JDO doesn't really need the second method, but it doesn't hurt) and each nonabstract class has a Synchronization instance property. As it's fairly easy to implement a MultiSynch object to multiplex Synch calls, and leaving the exact multiplexing strategy open has notable advantages, organization of multiple Synchronization objects under this interface is left to the developer (the singular property is sufficient). New DatabaseImpl objects are initialized with the JDO property but the DatabaseImpl's property can be overridden in user code. When commit() or rollback() are called, the appropriate Synchronization methods are called on the user callback objects and user code can now do useful things on transaction boundaries. Yay! I'll be implementing these changes tomorrow and writing some tests to make certain they work. Should be ready by Tuesday or Wednesday. How would I submit such changes for approval and getting them fed back into the source tree? If it was just extending DatabaseImpl and JDO it wouldn't be such a big deal, I could just have my local subclasses and never bother you guys, but I really want to go through the Database interface and that complicates things a bit. Regards, Ross -- Ross Bagley http://rossbagley.com/rba "Security is mostly a superstition. It does not exist in nature... Life is either a daring adventure or nothing." -- Helen Keller ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
