What's New in Apache Ignite.NET 1.8

DZone 's Guide to

What's New in Apache Ignite.NET 1.8

The newest version of Apache Ignite includes an entity framework second-level cache, ASP.NET session state cache, custom logging, and LINQ improvements.

· Big Data Zone ·
Free Resource

Apache Ignite 1.8 was released on December 9. Let’s see what's new in the .NET part.

ignite logo

Entity Framework Second-Level Cache

Apache Ignite is often used as a middle layer between disk-based RDBMS and the application logic to increase performance. A common approach is to implement a write-through and read-through cache store. However, this approach requires changing the existing data layer completely and switching to Ignite APIs.

There is now a new way to boost database performance in Entity Framework 6.x applications that requires only minimal configuration changes: Ignite EF 2nd Level Cache.

ASP.NET Session State Cache

ASP.NET stores session state data in memory by default. For web farms, there is SQL Server provider so that session state is shared between servers. Ignite offers distributed in-memory session state storage, which also shares data between servers but is faster and more fault tolerant than SQL Server.

Custom Logging

In previous Ignite.NET versions, all logging happened in Java. There was no possibility to configure logging or write to the log on .NET side.

The new version provides an ILogger interface and IgniteConfiguration.Logger property to define a custom logger, and there are ILogger implementations for NLog and log4net. When IgniteConfiguration.Logger  is not specified (default), old behavior with Java logging is in effect. When the property is set, all logs from Java and .NET are redirected to the specified implementation.

You can also write to the log (no matter if a custom logger is configured) via  IIgnite.Logger. The ILogger interface has only one logging method with all the details. The helper extension methods with simpler signatures are in the Apache.Ignite.Core.Log.LoggerExtensions class. This design means that ILogger implementors have only two methods to write and don’t have to inherit anything.

Here is an example of colorized console output using IgniteNLogLogger:

var logCfg = new LoggingConfiguration();
var target = new ColoredConsoleTarget();
logCfg.AddTarget("con", target);
logCfg.LoggingRules.Add(new LoggingRule("*", NLog.LogLevel.Info, target));

LogManager.Configuration = logCfg;

var cfg = new IgniteConfiguration
    Logger = new IgniteNLogLogger(),
    JvmOptions = new [] {"-DIGNITE_QUIET=false"}

var ignite = Ignition.Start(cfg);

ignite.Logger.Info("Hello World!");

Transaction Deadlock Detection

Ignite now detects deadlocks in pessimistic transactions automatically when transaction timeout is specified, and throws TransactionDeadlockException. See this documentation for more details.

New Examples

Binary and source distributions (available here) now include a lot more examples in platforms\dotnet\examples.

I like these three in particular:

  1. TransactionDeadlockDetectionExample shows how transaction deadlock can be caused, detected, and handled.
  2. BinaryModeExample demonstrates cache and SQL usage without classes, with dynamically generated entities.
  3. MultiTieredCacheExample shows how cache entries are stored in heap, off-heap, and swap memory.

LINQ Improvements

CompiledQuery is deprecated in favor of CompiledQuery2, which removes a lot of limitations:

  • Skip and take are supported.
  • Embedded arguments are allowed (.Where(x => x.Key > 5)).
  • Argument reuse is allowed (.Where(x=>x.Key > foo && x.Value.Id > foo)).

CompiledQuery2 has a similar API, but it takes Expression<Func<T1, IQueryableT>> instead of eFunc<T1, IQueryable<T>>, which allows better query inspection.

There is also a new method, CompiledQueryFunc Compile(IQueryable query), which compiles an existing query to a delegate IQueryCursor CompiledQueryFunc(params object[] args). This method provides a lot of flexibility because you can build LINQ expression dynamically, and it can have any number of arguments:

var cache = ignite.GetCache<int, Product>("products");
var qry = cache.AsCacheQueryable();

if (nameFilter != null)
  qry = qry.Where(x => x.Value.Name.Contains(nameFilter));

if (maxPrice != null)
  qry = qry.Where(x => x.Value.Price <= maxPrice);

var compiledQry = CompiledQuery2.Compile(qry);

The difference from other overloads here is that compiled delegate takes params object[] instead of specific argument types, so you have to carefully provide arguments in correct order.


There are a number of bugfixes and other improvements.

  • Query configuration supports nullable types.
  • NuGet upgrade procedure fixed (should no longer require manual bin folder cleanup)
  • IgniteConfiguration.WorkDirectory is no longer ignored in some cases

Documentation on apacheignite-net.readme.io has been improved in certain areas. Have a look at the following sections:

apache ignite ,big data

Published at DZone with permission of Pavel Tupitsyn . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}