Integration

I think I have previously been rambling about the lack of bulk lock / unlock API methods in the Coherence API:s but would still like to bring this up once more as an improvement proposal!

Assuming that one can find a locking order of the keys to lock firstly based on what node each key belongs to and secondly some other property of the key I believe that significant savings could be realized!

Lets assume that we need to lock 200 keys (for instance during the prepare phase of a transactional map) spread over say 10 nodes. If these keys are ordered first by currently assigned node and then by for instance binary ordering (treating each keys serialized form as a byte array that is compared bit by bit) no more than 10 remote calls (one to each node involved) would be required (they still need to be performed in sequence though) compared to 200 remote calls that is needed with todays single key lock method! In this case a 20 fold reduction in remote trips could be realized and assuming that all the locks immediately are granted (low contention environment) the speed up should be almost 20 fold as well!!!!!

I realize that if re-balancing would occur during a bulk lock request the full performance benefit would not be realized but I still belive it would be possible to make it work reliably!

If the Coherence team don't want to handle the complexity of ordering the keys even a bulk method call with an ordered structure (array, list etc) would be a big help. It would then be up to the developer to order the keys in a way that creates potential for reducing the number of remote calls required (i.e. implement similar logic as described above or some application specific logic with the same effect).

Ideally both types of methods (user specified or automatically calculated key ordering) could be provided....

The need for bulk methods also holds for releasing locks (here one could even have an option of releasing all the locks in parallel or in strict opposite order of the one used during locking). If unlocking in parallel can be used the speed-up is even better than 20 fold...

Comments, suggestions and critique is warmly appreciated - is this really a good idea or am I missing something obvious (or not so obvious) that makes my suggestion pointless?

/Magnus

Edited by: MagnusE on Jan 14, 2010 8:02 PM