18 messages in com.mysql.lists.javaRe: transactions no longer being comm...
FromSent OnAttachments
Jeff Mathis22 Jul 2003 15:25 
Jeff Mathis22 Jul 2003 15:35 
Mark Matthews22 Jul 2003 17:45 
Rakesh Ayilliath23 Jul 2003 06:01 
Shapiro, David23 Jul 2003 06:14 
Jeff Mathis23 Jul 2003 08:24 
Rakesh Ayilliath23 Jul 2003 08:25 
Christopher Taylor23 Jul 2003 18:44 
Jeff Mathis24 Jul 2003 08:20 
Jeff Mathis24 Jul 2003 12:43 
Jeff Mathis24 Jul 2003 13:25 
Mark Matthews24 Jul 2003 14:05 
Christopher Taylor24 Jul 2003 17:38 
Jeff Mathis25 Jul 2003 08:41 
Jeff Mathis25 Jul 2003 15:06 
Jeff Mathis25 Jul 2003 15:12 
Christopher Taylor25 Jul 2003 19:34 
Jeff Mathis28 Jul 2003 07:51 
Subject:Re: transactions no longer being committed
From:Jeff Mathis (jmat@predict.com)
Date:07/25/2003 03:12:49 PM
List:com.mysql.lists.java

looks like the bottom of my message got chopped ---

From a design point of view, I was thinking that maybe my objects shouldn't have a reference to the Connection that created them. Then sharing them between Connections wouldn't be an issue. All objects implement Comparable, which uses the row id in a table and the table name for unique identification, so I don't think a database deadlock would come about. What do you think?

Yes, it is a standalone application. I use multithreading to speed up data loading.

My schema is heirarchical. I have a few parent tables, and lots of child tables that refer to the parent tables via PK/FK constraints. My objects basically represent a row in a given table. For a child table, the constructors all take the parent object they are associated with, and then get their Connection object from that parent.

When I created separate threads (all in a ThreadGroup), each with their own Connection, I shared a set of parent objects loaded in the beginning of the application run from a Connection that was not in the new ThreadGroup. Hence, all child objects were referencing the parent objects Connection.

My data loader would then call commit() on the Connection belonging to an individual thread, which was not the correct one. I fixed the problem by adding a check in a central Store object, which holds a reference to the Connection, to make sure all objects in that Store have the right Connection. I'm using the mysql query "select connection_id()", which will return a unique connection id.