Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Prasanna.Santhanam@citrix.com
 designates 203.166.19.134 as permitted sender)
Date: Thu, 23 Aug 2012 20:19:43 +0530
From: Prasanna Santhanam <prasanna.santhanam@citrix.com>
To: CloudStack Dev <cloudstack-dev@incubator.apache.org>
Subject: About Transaction management
Message-ID: <20120823144943.GA24660@cloud.com>
Mail-Followup-To: CloudStack Dev <cloudstack-dev@incubator.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)

I was looking at moving the Simulator managed entities into a
different database and found that Transaction.java is not able to
switch to the right DB based on context of its execution.

To explain further:

The ServerResource for simulator which is the bottommost layer manages
a set of Daos which alter entities in the database : `simulator`. When
the context goes back to the middle manager layers of CS
(ResourceManagerImpl say) after a Command is executed at the
ServerResource all the Daos in the Managers seem to access the
`simulator` db instead of the `cloud` db for their operations.

I noticed that Transaction.java holds a threadlocal store where it
retains the _previously used database.

1) Is this a bad design for the simulator in that it tries to alter db
entities at the ServerResource?
2) Or is this a bug in the way transactions are managed? 
3) Or is this the wrong way to switch databases?

txn = Transaction.open(Transaction.SIMULATOR_DB)
try {
 	   txn.start();
		 .... some persistence code here....
		 txn.commit();

		} catch (Exception ex) {

		  txn.rollback(); 

		} finally {

			txn.close();

		}

Thanks,

-- 
Prasanna.,