Well, it depends on reads/writes and how much contention there is.  I certainly don't know your business requirement, but I generally like to spread out my K,V pairs.  ISPN certainly does support what you're doing.

For only updating a subset of an object, take a look at the DeltaAware implementation.  For your use case, the AtomicMap API may also be helpful.

I would start HERE for understanding ISPN's locking model and to formulate a design pattern (which may help your reported 5 minute lock).  From my perspective, if you expect a lot of contention and need to read the latest version, consider pessimistic locking of the form:

tm.begin();
myCache.lock( key );
Object o = myCache.get( key );

// Do something with o.
myCache.put( o );
tm.commit();

Earlier we were using a POJO cache and had only single POJO object which will store complete state of the cache. The object was assigned to single key.

 

Is it OK to move to infinispan with same setup (single key - single pojo object)? We want to understand if this setup will create any issues?

Infinispan won't intercept field level modifications, it'd be better if you split the object into several keys in order to assure granular state replication and allow multiple transactions to update the state concurrently.

Also if you're looking for an Infinispan based alternative to POJO cache's fine grained replication, you might want to consider Hibernate OGM: http://www.hibernate.org/subprojects/ogm.html