ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Igor Seliverstov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-7911) TX SQL: restrict usages of unsupported APIs and configuration parameters
Date Thu, 22 Mar 2018 13:00:00 GMT

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

Igor Seliverstov commented on IGNITE-7911:

[~al.psc], see comments below:

1) I think it's better to create static method {{verifyOperationSupport(GridCacheContext cctx,
String op)}} in {{MvccUtils}}
 2) "SQL operations are forbidden within non-SQL transactions." sounds unclear, "Cannot mix
DML and cache API calls within the same transaction." or something similar sounds better from
my point of view.
 3) We need to support SqlQueries and SqlFieldsQueries as well, currently an attempt to query
cache without JDBC produces exception.
 4) org.apache.ignite.internal.processors.cache.jta.CacheJtaManager compile time exception

> TX SQL: restrict usages of unsupported APIs and configuration parameters
> ------------------------------------------------------------------------
>                 Key: IGNITE-7911
>                 URL: https://issues.apache.org/jira/browse/IGNITE-7911
>             Project: Ignite
>          Issue Type: Task
>          Components: cache, sql
>            Reporter: Vladimir Ozerov
>            Assignee: Alexander Paschenko
>            Priority: Major
>             Fix For: 2.5
> We need to make sure that when MVCC flag is enabled, users get correct exception in case
of invalid configurations and/or API usages. Two general rules should apply
> 1) SQL and cache operations cannot be mixed in the same transactions because they still
use different APIs. This restriction will be removed in future when native cache API is reworked
to new locking logic.
> 2) If configuration is invalid or not-yet-supported API is called, user gets correct
exception instead of invalid result.
> All listed cases must be covered with tests.
> Checklist:
> 1) Cache configuration
> 1.1) Cache store is not allowed for TX caches
> 1.2) Expiry policy is not allowed for TX caches
> 1.3) Interceptors are not allowed for TX caches
> 2) Cache API unsupported operations - throw UnsupportedOperationException and create
relevant ticket (if one doesn't exist):
> 2.1) withExpiryPolicy 
> 2.2) Continuous queries
> 2.3) "clear" method family 
> 2.4) "lock" method family 
> 2.5) "load" method family 
> 2.6) "peek" method family 
> 2.7) "evict" method family
> 3) Cache API consistency - make sure that these operations use consistent snapshot assigned
to transaction (as with other operations). If this is the case - do nothing; if this is not
the case - throw UnsupportedOperationException and create a ticket (if one doesn't exist)
> 3.1) Scan queries
> 3.2) "size" method family
> 3.3) Iterator methods (iterator, localEntries)
> 4) Mixed native API and SQL usage is restricted and proper IgniteException is thrown.
When snapshot is requested for the first time we should mark transation as either "SQL" or
"native". If any SQL query is executed on "native" transaction or vice versa throw an exception
(IllegalStateException? IgniteException?)

This message was sent by Atlassian JIRA

View raw message