Hi Wasif Riaz Malik,
Just to add to what Andrew says, ClusterJ does try to start a
transaction on the ndbd node most likely to contain the data. It does
this by using the ndb api to set the partition key for the transaction
before starting the transaction. The partition key used is based on
the primary key value of the first operation defined in the
transaction. The ndb api then chooses the best transaction coordinator
for the particular transaction.
Queries that are not primary key queries don't benefit from partition
key awareness so I'd expect these transactions to show a more random
pattern of transaction coordinator node.
On Jun 18, 2012, at 7:06 AM, Andrew Morgan wrote:
> Not specific to ClusterJ but for primary key lookups, the NDB API
> client library hashes the primary key (or a sub-component of the PK
> if you tell it to) to see what partition the data is in - it then
> sends the operation to the primary data node for that partition.
> Clusterj uses the NDB API and so I'd expect the behaviour to be
> More on making your app/schema "distribution aware" can be found at
> Regards, Andrew.
>> -----Original Message-----
>> From: Wasif Riaz Malik [mailto:wmalik@stripped]
>> Sent: 18 June 2012 14:10
>> To: cluster@stripped
>> Subject: ClusterJ distribution awareness
>> I am using ClusterJ 7.1.15a to query a cluster of ten nodes. I have
>> noticed that the transactions are sent only to three nodes (even
>> the data is evenly spread out on all ten nodes).
>> How does clusterj decide the transaction coordinator be default (if
>> hints are given)? Is it possible to distribute the transactions in a
>> round robin fashion (without passing hints for each transaction)?
>> Wasif Riaz Malik
> MySQL Cluster Mailing List
> For list archives: http://lists.mysql.com/cluster
> To unsubscribe: http://lists.mysql.com/cluster
Craig L Russell
408 276-5638 mailto:Craig.Russell@stripped
P.S. A good JDO? O, Gasp!