Application Development Meanderings

Based on my previous post, I have been looking into AOP as a way to help with long conversations. The thinking is that I want to create DAOs and other data access objects but not specifically break spring and hibernaet provided methods. Spring itself uses a proxy object on the session factory so that when you create a new session, spring

Based on my previous post, I have been looking into AOP as a way to help with long conversations. The thinking is that I want to create DAOs and other data access objects but not specifically break spring and hibernate provided methods. Spring itself uses a proxy object on the session factory so that when you create a new session, spring "catches" the call for a new session using the proxy, then manages the session for you. In a similar way, you really need to make the use of long conversations (an extendend persistent context) more optional and transparent to data access objects. AOP is a good way to do this. Also, after much consideration, I do believe that in a RCP setting, long conversations are highly application specific but I think they do share characterstics that are very different than web applications. Web applications have better mechanisms for indicating a start and stop approach (a transaction for example). In a RCP, depending on the application, it may be diffi

After much thought it appears that easily grafting long conversation support into standard spring is challenging. It forces code into the DAOs that should be made more transparent--perhaps through AOP etc--but is a twisting of how some of the core classes in spring work around hibernate (which is based more or less on session-per-request). The way I see it, the two key classes are SessionFactoryUtils and SynchronizationTransactionManager. The STM class is merely a way to stash global variables on the thread. They can be keyed (because the data is stored in a hashmap inside of the STM class) so it is a general purpose mechanism. STM also has TransactionSynchronization support which are really just listener objects listening to transaction events such as begin, commit, etc--its a transaction specific listener/observer pattern. The real crux is probably in the SessionFactoryUtils class. This class supports getting the current session from the STM based on the session factory. In the case