ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: Integrating cache store with Spring transaction manager
Date Wed, 13 May 2015 06:14:34 GMT
Val, I agree with your suggestion.


2015-05-13 5:43 GMT+03:00 Valentin Kulichenko <valentin.kulichenko@gmail.com

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message