...
Apache Ignite 2.0 is based on the new page memory architecture. Data is always stored offheap, with ability to optionally cache small portion in Java heap. Please refer to documentation to learn more about new concepts and configuration parameters See documentation for more information [1].
...
Previously existed eviction mechanisms based on EvictionPolicy
is now supported only for optional near and Java heap caching of the data stored in the offheap page memory. To enable the eviction for the page memory, use DataPageEvictionMode
enumeration. See documentation for more details [2] for more details.
memoryMode
property has been removed due to new Ignite page memory architecture [1]...
IgniteAsyncSupport
interface is now deprecated and will be removed in future Apache Ignite releases. Use methods with Async
suffix instead. See documentation for more information [4] for more information.
Old style:
Code Block |
---|
IgniteCache<K, V> asyncCache = cache.withAsync(); asyncCache.getAsync(key); IgniteFuture<V> future = asyncCache.future(); |
...
Service Grid calls are now processed in dedicated thread pool (see IgniteConfiguration.serviceThreadPoolSize
property)
IgniteConfiguration.dataStreamerThreadPoolSize
property)IgniteConfiguration.queryThreadPoolSize
property)Utility has been removed. Please use Web Console [7].
...
Apache Ignite 2.0 integrates with Hibernate 5.0. The previous integration with a legacy Hibernate version of 4.2 can be used by importing ignite-hibernate_4.2
maven artifact or taking a respective JAR file from distribution. See documentation for more details [65]
Default Redis cache name was changed from null
to default
. See documentation for more details [56]
...
Class was removed. Please use CompiledQuery
.
LockId
property
...
has been removed.
...
DefaultNameMapper
- > renamed to NameMapper
, DefaultIdMapper
- > renamed to IdMapper
, DefaultKeepDeserialized
- > renamed to KeepDeserialized
...
Renamed to ILifecycleHandler
. {{IgniteConfiguration.LifecycleBeans
...
}} property renamed to IgniteConfiguration.LifecycleHandlers
.
BinaryConfiguration
is is no longer required - , any type can be used in Cache and Compute right away. All objects are written in Ignite binary format (which means IBinary and SQL APIs always work).Serializable types (including those which implement ISerializable) are also written using Ignite binary format. Learn more from this documentation: https://apacheignite-net.readme.io/docs/serialization, including types implementing interface. See documentation for more information [8].
Ignite.NET 1.9 and earlier uses simple name mapping only, which means objObject.GetType().Name
is is used to map type name to type id. Ignite.NET 2.0 uses full name mapping by default, which includes namespace, generics and array dimensions. This change affects may affect multi-platform Ignite applications where Java and .NET types are mapped to each other. More details: https://apacheignite-net.readme.io/docs/platform-interoperability
Schema import utility - ?
See documentation for more information [9].
CachePeekMode: IGNITE_PEEK_MODE_*
->
CachePeekMode::*
(e.g. IGNITE_PEEK_MODE_PRIMARY -> CachePeekMode::PRIMARY
)TransactionConcurrency: IGNITE_TX_CONCURRENCY_* -> TransactionConcurrency::*
(e.g. IGNITE_TX_CONCURRENCY_OPTIMISTIC -> TransactionConcurrency::OPTIMISTIC
)TransactionIsolation: IGNITE_TX_ISOLATION_* -> TransactionIsolation::*
(e.g. IGNITE_TX_ISOLATION_READ_COMMITTED -> TransactionIsolation::REPEATABLE_READ
)TransactionState: IGNITE_TX_STATE_* -> TransactionState::*
(e.g. IGNITE_TX_STATE_ACTIVE -> TransactionState::ACTIVE
)CollectionType: IGNITE_COLLECTION_* -> CollectionType::*
(e.g. IGNITE_COLLECTION_ARRAY_LIST -> CollectionType::ARRAY_LIST
)MapType: IGNITE_MAP_* -> MapType::*
(e.g. IGNITE_MAP_HASH_MAP -> MapType::HASH_MAP
)IgniteError
now should be passed by reference and not by pointer everywhere.
BinaryWriter::WriteObject
and BinaryRawWriter::WriteObject
now take constant references instead of value. This probably won't require any changes from you.
BinaryType
have been heavily refactored:
BinaryType
methods, meaning you are now going to have compilation errors instead of runtime errors if you have not implemented some essential method for your binary type. If you don't want to implement some method and you are sure that you will not be needing it then you should explicitly provide implementation of such method which asserts or throws exception upon call.GetHashCode
and GetIdentityResolver
methods are not used any more.BinaryType::Write
now takes object argument by constant reference and not by value: void Write(BinaryWriter&, T) -> static void Write(BinaryWriter&, const T&)
BinaryType::Read
now returns object by argument reference and not as return value (method does not return any value any more): T Read(BinaryReader&) -> static void Read(BinaryReader&, T&)
BinaryType::GetTypeName
now return name by argument reference and not as return value: std::string GetTypeName() -> static void GetTypeName(std::string&)
BinaryType::GetNull
now return null value by argument reference and not as return value: T GetNull() -> static void GetNull(T&)
QueryArgument
and QueryArgumentBase
classes are not public any more. This should not affect any users as these classes were not meant for use by users from the beginning.Cache plugins - ?
[1] https://apacheignite.readme.io/docs/page-memory
...
[4] https://apacheignite.readme.io/docs/async-support
[5] https://apacheignite-mix.readme.io/docs/hibernate-l2-cache
[6] https://apacheignite.readme.io/docs/redis
[7] https://apacheignite-tools.readme.io/docs/automatic-rdbms-integration
[86] https://apacheignite-mixnet.readme.io/docs/hibernate-l2-cache/serialization
[9] https://apacheignite-net.readme.io/docs/platform-interoperability