Instead of deprecation, how about creating CacheSpringStore with required start and end callbacks?
D. On Tue, May 12, 2015 at 11:14 PM, Yakov Zhdanov <[email protected]> wrote: > Val, I agree with your suggestion. > > --Yakov > > 2015-05-13 5:43 GMT+03:00 Valentin Kulichenko < > [email protected] > >: > > > Igniters, > > > > I'm currently working on this ticket: > > https://issues.apache.org/jira/browse/IGNITE-891 and I have a couple of > > thoughts about current cache store design. What I don't like about it, is > > that we have only sessionEnd callback, but not sessionStart. We assume > that > > the flow is the following: > > > > - on each store operation user tries to get a connection from session > > - if connection is there, use it to update or query DB > > - otherwise, create a new connection and attach it to session > > - when sessionEnd is called, do commit or rollback > > > > This is OK for plain JDBC because user can't do anything until he has a > > Connection object in hands, so he is FORCED to execute some logic that > will > > create it if needed. The same goes for Hibernate as there is a Session > > object which is similar to Connection in this case. > > > > But Spring (and I believe this is not the only example) is different. Its > > transaction manager allows to start a transaction and gives you a handle > > which can be used only for commit or rollback. Any operations executed in > > the same thread via Spring's APIs (JdbcTemplate, HibernateTemplate, etc.) > > will participate in this transaction. So user is not forced to execute > the > > logic that will start a transaction if it's not started yet. This is > > error-prone - a stupid mistake can cause DB operations to execute outside > > of transaction. > > > > sessionStart callback will help and will make store API more generic. But > > we can't add it directly to store w/o breaking compatibility, so I > suggest > > to add new interface: > > > > public interface CacheStoreTransactionAware { > > public void onTransactionStart(); > > > > public void onTransactionEnd(boolean commit); > > } > > > > A store can optionally implement this interface. If it does, > > onTransactionEnd replaces sessionEnd and we also have onTransactionStart. > > Otherwise, sessionEnd works as earlier. > > > > sessionEnd can be deprecated in favor of new interface. > > > > Thoughts? > > > > -- > > Val > > >
