ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Kuznetsov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-1553) Optimize transaction prepare step when store is enabled
Date Mon, 18 Dec 2017 17:06:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16295263#comment-16295263
] 

Alexey Kuznetsov commented on IGNITE-1553:
------------------------------------------

[~agoncharuk] Currently we have a couple of CacheStore implementations : GridCacheWriteBehindStore,
and GridCacheLoaderWriterStore which don't support sessionEnd() method(No-op implementation).
This means that we cannot commit to database as you described in ticket description above,
instead data is persisted right after calling write\delete etc.
Additionally, we cannot guarantee that custom CacheStore prepares data for commit when write\delete
etc. is called (and we cannot guarantee that data is flushed when sessionEnd is called)

So, I would propose to optimize prepare step only if CacheStore is instance of CacheAbstractJdbcStore
or CacheJdbcBlobStore(only these stores guarantee autocommit==false)

> Optimize transaction prepare step when store is enabled
> -------------------------------------------------------
>
>                 Key: IGNITE-1553
>                 URL: https://issues.apache.org/jira/browse/IGNITE-1553
>             Project: Ignite
>          Issue Type: Improvement
>          Components: cache
>    Affects Versions: ignite-1.4
>            Reporter: Alexey Goncharuk
>            Assignee: Alexey Kuznetsov
>              Labels: important
>
> Currently entries are enlisted in a database transaction after grid transaction is in
PREPARED state. We can do this in parallel in the following fashion (pseudo-code):
> {code}
> fut = tx.prepareAsync();
> db.write(tx.writes());
> fut.get();
> try {
>     db.commit();
>     
>     tx.commit();
> }
> catch (Exception e) {
>     tx.rollback();
> }
> {code}
> If this approach is applied, we should be able to reduce latency for transactions when
write-through is enabled.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message