On Mon 26 Nov 2012 04:33:57 PM CET, Graeme Wallace wrote:
> I've tried playing around with transaction size, but the error still
> remains even if I make the transaction small ie 32K rows AND i make all the
> primary keys unique - so that each transaction should have a unique set of
> On Mon, Nov 26, 2012 at 8:30 AM, Magnus Blåudd
>> On Mon 26 Nov 2012 04:09:42 PM CET, Graeme Wallace wrote:
>>> I'm trying to make my app multi-threaded and running into
>>> I have a Session local to each thread that is attempting to write to the
>>> db. I'm batching up many savePersistent() calls in a transaction - but
>>> the transaction commits I invariably end up with
>>> Nov 21, 2012 7:22:29 PM com.mysql.clusterj.tie.Utility throwError
>>> SEVERE: Error in NdbJTie: returnCode -1, code 266, mysqlCode 146, status
>>> classification 10, message Time-out in NDB, probably caused by deadlock .
>>> For reading the docs, it looks like there shouldn't be table locking going
>>> on - so i dont understand what resource is being held by one thread that
>>> stops the others from being able to write at the same time.
>>> Any clues would be most helpful,
>> Check out Matthew's reply in in this forum thread
>> "Due to the distributed nature of NDBCLUSTER there is no automatic
>> deadlock detection mechanism within the NDBCLUSTER engine. The only
>> indication that the cluster gives that there is a *possible* deadlock is
>> the "Lock wait timeout exceeded". This error occurs when a given lock
>> operation takes longer than TransactionDeadlockDetectionTi**meout
>> (default 1200 ms.). If you have large transactions that lock many rows at
>> once or if you have long running transactions these can prevent this or
>> transactions from completing quickly. Try to avoid large or long running
>> transactions by breaking them into smaller chunks. The
>> TransactionDeadlockDetectionTi**meout can also be reached when a node is
>> overloaded but has not yet been ejected from the cluster for missing
>> heartbeats longer than 4xHeartbeatIntervalDbDb (default 1500 ms. each). "
>> / Magnus
Give it a try with even smaller transactions if possible. Normally
better to use more threads with smaller transactions.