VMware

vFabric GemFire Native Client 3.6.0 Release Notes

vFabric GemFire Native Client 3.6.0 | 14 SEPT 2011

Last Document Update: 14 SEPT 2011

VMware® vFabric™ GemFire® Native Client provides access to the vFabric GemFire distributed system for C++ and Microsoft® .NET™ clients. For information on setting up GemFire for use by your native client applications, see the vFabric GemFire documentation.

What's in the Release Notes

The release notes cover the following topics:

What's New in vFabric GemFire Native Client 3.6.0

This section summarizes new functionality in vFabric GemFire Native Client 3.6.0 and refers you to more detailed information in the GemFire documentation.

Support for .NET Generics

The .NET API now supports .NET generic types. The new API is in GemStone::GemFire::Cache::Generic. You can still use the non-generic GemFire APIs in GemStone::GemFire::Cache. The non-generic Cache APIs are deprecated, but still completely functional in this release. Do not mix Cache with Cache::Generic or you will get errors at runtime. Declarative configuration via XML of user plugins such as cachelistener, cachewriter, cacheloader and
partitionresolver is not supported when clients are operated in the new .NET Generics API.

In the GemFire Native Client User's Guide, see "The .NET Caching API."

Portable Data eXchange Serialization for .NET

GemFire has a new, more feature-rich option for data serialization for the .NET client. This is in addition to the existing data serializable option.

Note: PDX serialization cannot be used for data that may be exchanged with C++ clients.

GemFire's Portable Data eXchange (PDX) serialization format provides the following:

  • Domain object versioning. Add or remove fields in your domain objects without having to stop the entire GemFire system. GemFire manages multiple versions of domain objects in the cache, allowing you to gradually introduce new versions of your applications.
  • Language independence. Define serialization for your domain objects on a .NET client. Store, query, and run functions against the domain objects on the servers without defining the objects on the Java server. This feature allows you to manage the objects in the client without needing to create Java classes for the server side.
  • Reduced deserialization of serialized objects. The access methods for PdxSerializable objects allow you to examine specific fields of your domain object without deserializing the entire object. Depending on your object usage, this can cut down significantly on serialization and deserialization costs. The query engine automatically recognizes PDX objects, retrieves the PdxInstance of the object and uses just the fields it needs.
  • Automatic reflection-based serialization. You can configure your cache to automatically serialize and deserialize domain objects without having to add any extra code to them.

In the GemFire Native Client User's Guide, see the information on data serialization in "The .NET Caching API."

Client-Initiated Transactions

GemFire now supports transactions run from a client member. Previously, to perform a transaction from a client member, you needed to run a function on a server node that executed a transaction. In the GemFire Native Client User's Guide, see the "Transactions" chapter.

Licensing Changes

The GemFire licensing model has changed to more closely resemble VMware's licensing model. You no longer need to provide licensing information to your client applications. All licensing for clients is provided in the server side. The peer/server licensing has new configuration requirements.

In the vFabric GemFire User's Guide under Deploying and Running vFabric GemFire, see the "Licensing" chapter.

Change to Order of Method Calls for Reconnecting Durable Clients

The order of your method calls on durable client reconnection needs to be changed. Before this version, you created your cache and regions, called Cache.readyForEvents, then called your interest registration methods. The order of the last two steps needs to be switched. The new instructions read as follows:

Program the durable client to perform these steps, in order, when it reconnects:

  1. Create the cache and regions. Ensures that all cache listeners are ready. At this point, the application hosting the client can begin cache operations.
  2. Issue the register interest requests. Allows the client cache to be populated with the initial interest registration results. The primary server responds with the current state of those entries if they still exist in the server’s cache.
  3. Call Cache.readyForEvents. Tells the servers that all regions and listeners on the client are now ready to process messages from the servers. The cache ready message triggers the queued message replay process on the primary server.

Modify your durable client code accordingly.

Support for Query Bind Parameters from Clients

Added support for query bind parameters in client queries.

High Availability for OnServer Function Execution

OnServer function execution now supports high availability (HA).

Pool Default Settings Changed to Match the Settings for Java Client

Pool default settings now are the same as the Java client. Review your pool configurations to make sure they are appropriate.

New setPartitionResolver Function

It is now possible to set a partition resolver through the C# setPartitionResolver function.

Resolved Issues

The following issues have been resolved in this release.

ContainsKeyOnServer Caused Infinite Loop

Modified ContainsKeyOnServer so it correctly passes security credentials to the server when security is enabled. Before this version, ContainsKeyOnServer did not pass credentials, which caused an infinite loop when it was called. This issue was tracked with bug 667 and customer support ticket 7549.

Authentication Failure with Security and Fire-and-Forget Functions

Resolved a problem that caused authentication to fail if security was enabled and a fire-and-forget function call was made from the client.

Improper Firing of AppDomain Event Handling

AppDomain UnhandledException event user handler now fires properly.

Known Issues

This section lists known issues in the GemFire product and its supported platforms.

Non-Primitive Key Types Require a Java Class Registered with the Cache Server

For non-primitive key types, a Java class defining the type is needed so the cache server can store the value in the cache. The applications accessing the cache may not involve Java at all, but the Java class still needs to be written and registered with the cache server.

Timeout Can Occur While Registering Interest in a Large Number of Keys

Individually registering interest in a large number of keys can result in a timeout condition. Instead, call registerAllKeys if you need to register interest in thousands of keys on the server.

Requirements for Non-Primitive Key and Value Types

Non-primitive objects that require deserialization on the server must have their Java classes registered on the server. This affects keys and values in these ways:

  • Key Types. The GemFire cache server stores keys in deserialized form, so the Java classes of all non-primitive key types must be registered on the cache server.
  • Value Types. Indexing and querying require values to be deserialized, to the Java classes of non-primitive value types must be registered on the cache servers for all regions that are indexed or queried on the server.