Solved

JDBC Connection sharing in a JTA Transaction

Posted on 2004-08-10
4
551 Views
Last Modified: 2013-12-10
I m using weblogic 8.1 and oracle XA driver.

If i create 2 different connections using the same DataSource in the same JTA transaction, will weblogic return 2 physical different connections or the same connection object.

the use case is that i use entity beans and DAO in the same transaction. entity beans to update data and DAO to read some data.

My concern is that, can DAO access data that is inserted by entity beans in the same transaction.

Weblogic docs say that in case of non-XA driver, the same connection object is used in  a single transaction.

Please advise,

thanks,
venkat
0
Comment
Question by:venkatray
4 Comments
 
LVL 3

Accepted Solution

by:
yuvalg earned 63 total points
ID: 11771719
If there is only one database involved i think it will only be one connection.
The way that containers manage transactions is by associating a current thread with a specific db connection that can be used to either commit or rollback transactions.

If you are still not sure, there is a way to findout.
Within your code, ask for several connections from the datasource, then print their hashcode .

System.out.println( myConnection.hashCode() );

If the hashcode is the same, this is the same connection object.

Yuval.
0
 
LVL 23

Assisted Solution

by:rama_krishna580
rama_krishna580 earned 62 total points
ID: 11803095
HI,

the DAO pattern is usually associated with entity beans with Bean-Managed Persistence (BMP). However, it can be used anywhere in a J2EE application. Entity beans provide a similar abstraction between business logic and persistence storage, but they lock us into one way of accessing data and one particular O/R mapping solution: the DAO pattern leaves us a choice. For example, we can use JDBC, JDO or entity beans to implement DAO interfaces. The DAO pattern also has the important advantage of working inside or outside an EJB container: often we can use the same DAO implementations in either location, which increases the flexibility of our architecture.

The DAO pattern differs from entity beans or O/R mapping approach in that:
It isn't necessarily based around O/R mapping. Whereas O/R mapping is concerned with nouns, such as a Customer or an Invoice, persistence facades can also deal with verbs, such as "total the amounts of all invoices for a given customer". Yet a DAO implementation may use an O/R mapping approach. DAO interfaces will use domain objects (such as Customer or Invoice) as necessary as method arguments and return values, to allow database-agnostic invocation from business objects.
It's a lightweight approach, based on good OO design principles. It uses ordinary Java interfaces, rather than special infrastructure such as that associated with entity beans.
It does not aim to handle transactions or security, but leaves this to business logic components.
It works with any underlying persistence technology.

With the DAO pattern the business logic determines the data access interfaces. With O/R mapping there is a risk that the data layer will dictate the working of the business logic layer. This is one of the reasons I'm skeptical about object-driven modeling. I have often seen situations where the modeling of one entity bean per RDBMS table dictates the nature of session bean code and results in excessive complexity. This is the tail wagging the dog: the point of an application is to express business rules, not work with a predetermined and possibly artificial data structure.

The following two diagrams illustrate how the DAO pattern can be used to conceal very different data access strategies from a business object. Both illustrate the use of a DAO implementing a MyDAO interface. The left hand diagram (Scenario 1) illustrates use of an implementation of this interface that uses JDBC. The right hand diagram (Scenario 2) illustrates use of an implementation that uses a layer of entity beans to abstract access to the RDBMS. Although the resulting architectures look very different, because the business object accesses the DAO through a fixed interface there is no need for changes in business logic to accommodate these two data access strategies.

DAOs, like business objects, are part of an application's middle tier.

In Chapter 9, we'll look at how to implement the DAO pattern to cleanly decouple business logic from persistence logic. We'll also use this pattern in our sample application.

and look at http://itadvisor.info/doc/14180 also...

i hope this may help you..
best of luck..

R.K
0

Featured Post

Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

Join & Write a Comment

Configure Web Service (server application) I. Configure security for Web Services methods First, we need to protect Session bean which implements the service: 1. Open EJB deployment descriptor (ejb-jar.xml) in the EJB project that contains you…
Upgrading Tomcat – There are a couple of methods to upgrade Tomcat is to use The Apache Installer is to download and unzip and run the services.bat remove|install Tomcat6 Because of the App that we are working with, we can only use Tomcat 6.…
This video discusses moving either the default database or any database to a new volume.
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now