Hello,
I am waiting for the response. In the mean time what I did was the
following.
Please refer the sample codes below -
To the AccountInfoDAO, I passed the session context (from
AccountManagerBean). Whenever there is an exception in the methods of the
AccountInfoDAO, I call
sesContext.setRollbackOnly();
This means that the DAO sets the rollback flag for the session bean. I feel
this very awkward but this seems to be the only combination working for me.
Could someone tell me whether this is the right approach or suggest a more
correct way of doing this.
Thanx a lot in anticipation
Jeetendra Dassani
Lead Systems Engineer
Tata Infotech Limited
SEEPZ, Andheri (E)
Mumbai.
Email : [EMAIL PROTECTED]
[EMAIL PROTECTED]
Telephone: 8291261 X 2775/2465
-----Original Message-----
From: Jeetendra [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 12, 2001 10:13 AM
To: '[EMAIL PROTECTED] '
Subject: RE: Data Access Patterns
Hello,
The application server used is Orion 1.5.2. The database is Oracle 8i. I
have a connection pool set up in orion for Oracle 8i.
As for the code here is the skeleton
----------------------------------------------------------------------------
------------------
// Name : BankingFacadeSessionBean
// Description: This bean will be an entry point for all the clients. It
will inturn call other //session beans to service client requests.
public class BankingFacadeSessionBean extends SessionBean
{
// This methods takes in the account details and the list of customers
that hold the //account
// Transaction Attribute : REQUIRESNEW
public void openNewAccount(AccountInfoVO refAccountInfoVO, int[]
iCustomerNumber)
{
//lookup for AccountManagerBean and then call the methods
int iAccountId = refAccountManagerBean.openNewAccount(refAccountInfoVO);
refAccountManagerBean.addCustomerToAccount(iAccountId, iCustomerNumber);
}
}
----------------------------------------------------------------------------
------------------
----------------------------------------------------------------------------
------------------
// Name : AccountManagerBean
// Description: The session beans carries operations relating to the account
public class AccountManagerBean extends SessionBean
{
// Transaction Attribute : REQUIRED
public int openNewAccount(AccountInfoVo refAccountInfoVO)
{
// Instantiate the DAO object and pass the initial context to it
AccountInfoDAO ref = new AccountInfoDAO(initContext);
int iAccountId = ref.insertAccountRecord(refAccountInfoVO);
}
// Transaction Attribute : REQUIRED
public void addCustomerToAccount(int iAccountId, int[] iCustomerId)
{
// Instantiate the DAO object and pass the initial context to it
AccountInfoDAO ref = new AccountInfoDAO(initContext);
ref.addCustomerToAccount(iAccountId, iCustomerId);
}
}
----------------------------------------------------------------------------
------------------
----------------------------------------------------------------------------
------------------
// Name : AccountInfoDAO
// Description : Helper to insert/update/delete/select from database.
Abstract Database access
public class AccountInfoDAO
{
DataSource ds;
public AccountInfoDAO(InitialContext initContext)
{
// OracleDS is the name of the pool for connecting to Oracle
ds = (DataSource) initContext.lookup("jdbc/OracleDS");
}
public void getConnection()
{
return ds.getConnection();
}
public void releaseConnection(Connection con)
{
con.close();
}
public int insertAccountRecord(AccountInfoVO refAccountInfoVO)
{
Connection con = getConnection();
Statement stmt = con.createStatement();
String str = "insert into account_info .......";
stmt.executeUpdate();
releaseConnection(con);
}
public void addCustomerToAccount(int iAccountId, int[] iCustomerId)
{
Connection con = getConnection();
Statement stmt = con.createStatement();
for(int i=0;i<iCustomer.length;i++)
{
String str = "insert into Customer_Account_Table .......";
stmt.executeUpdate();
}
releaseConnection(con);
}
}
----------------------------------------------------------------------------
------------------
Just to reiterate the problem. In the above pattern whenever I cannnot
insert in Customer_Account_Table, the insert in Account_Info must also be
rolled back.
Note:
1) The connection are obtained from the Connection Pool
2) Insert into table is done inside methods of data source
The question is does the transactional context of the bean methods extend
to the Java class as well making the two methods of the DAO work in one
Transaction.
Thanx a lot in anticipation
Jeetendra Dassani
Lead Systems Engineer
Tata Infotech Limited
SEEPZ, Andheri (E)
Mumbai.
Email : [EMAIL PROTECTED]
[EMAIL PROTECTED]
Telephone: 8291261 X 2775/2465
-----Original Message-----
From: Jay Walters [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 11, 2001 9:57 PM
To: 'Jeetendra '; '[EMAIL PROTECTED] '
Subject: RE: Data Access Patterns
We need some more information about the actual code you were using, how you
are getting the connections, etc. You can get this to work the way you want
to (a single transaction), there is just something off a bit. What
appserver are you using, what database?
Cheers
-----Original Message-----
From: Jeetendra
To: [EMAIL PROTECTED]
Sent: 9/11/01 10:56 AM
Subject: Data Access Patterns
Hello,
We had initiated this discussion a few days ago. I am looking for some
comments on my implementation of this pattern. Here is the description
1) I have a Session bean (as Session Facade) which has a method to open
a
new account (lets call it sf_method1 representing method1 of session
facade). Opening a new account requires us to insert the account
information
in the database and to link this account to a customer.
1.1) The method in Session Facade (sf_method1) calls sb_acct_method1
(method1 of account session bean). This method will insert the account
information in the database. To insert this data it makes use of a data
access object. Say it calls the method dao_method1 where dao_method1
will
insert the data (account information) in the accounts table.
1.1.1) dao_method1 obtains a connection from the connection pool by
looking
up for the data source object (javax.sql.DataSource). It then inserts
the
account information in account_info table
1.2) The next method called by session facade bean is sb_acct_method2
(method2 of the same session bean as in step 1.1) . This method inserts
a
records in Customer_Account table. This table merely contains two
columns -
Customer_Id and Account_Id. Even this method uses the abovementioned DAO
to
insert the data in Customer_Account table. Say it calls dao_method2.
1.2.1) dao_method2 obtains a connection from the pool and inserts the
data
in Customer_Account table.
The question is whether and how do I use declarative transactions?
I have declared the attribute of sf_method1 as REQUIRESNEW and that of
sb_acct_method1 and sb_acct_method2 as REQUIRED.
In the dao_method2 I have a division by zero exception. When I run the
client, the data is inserted in the account_info table (whereas I did
not
expect it because the second part of the transaction namely inserting
into
Customer_Account table) failed .
What I could derive from this is
1) The transactional scope of a method (of a bean) does not extend to
Java
classes that it might be calling.
2) By using DAO patterns, the transaction management becomes the
responsibility of the programmer.
Please let me know if I have got it wrong.
I was also wondering about the usability of this pattern in areas where
we
have only session beans. This ofcourse goes with the assumption that we
cannot extend transactional scope of a bean to the Data Access Objects.
Does
merely seperating the data access logic justify the cost of managing
transactions?
Thanx a lot in anticipation
Jeetendra Dassani
Lead Systems Engineer
Tata Infotech Limited
SEEPZ, Andheri (E)
Mumbai.
Email : [EMAIL PROTECTED]
[EMAIL PROTECTED]
Telephone: 8291261 X 2775/2465
========================================================================
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
