About Transaction management

[Prasanna Santhanam <pr...@citrix.com>]

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.,

RE: About Transaction management

[Edison Su <Ed...@citrix.com>]

> -----Original Message-----
> From: Prasanna Santhanam [mailto:prasanna.santhanam@citrix.com]
> Sent: Thursday, August 23, 2012 7:50 AM
> To: CloudStack Dev
> Subject: About Transaction management
> 
> 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?

Transaction.java has only one database(cloud) in mind, so if you change the database in transaction, then need to switch back to cloud.
You will find the following code in usagemanagerImpl all over the place:
    // switch back to CLOUD_DB
                Transaction swap = Transaction.open(Transaction.CLOUD_DB);


>

> 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.,

Re: About Transaction management

[Chiradeep Vittal <Ch...@citrix.com>]

On 8/23/12 7:49 AM, "Prasanna Santhanam" <pr...@citrix.com>
wrote:

>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?

Sounds like the DAO/Transaction stuff was not designed for this usage.

>2) Or is this a bug in the way transactions are managed?

It is designed this way. You could execute the transaction in a different
thread I suppose.

> 
>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.,