Solved

JDBC Connection sharing in a JTA Transaction

Posted on 2004-08-10
4
558 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

Gigs: Get Your Project Delivered by an Expert

Select from freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely and get projects done right.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

-Xmx and -Xms are the two JVM options often used to tune JVM heap size.   Here are some common mistakes made when using them:   Assume BigApp is a java class file for the below examples. 1.         Missing m, M, g or G at the end …
This exercise is about for the following scenario: Dmgr and One node with 2 application server. Each application server contains it owns application. Application server name as follows server1 contains app1 server2 contains app1 Prereq…
This Micro Tutorial demonstrates using Microsoft Excel pivot tables, how to reverse engineer competitors' marketing strategies through backlinks.
Although Jacob Bernoulli (1654-1705) has been credited as the creator of "Binomial Distribution Table", Gottfried Leibniz (1646-1716) did his dissertation on the subject in 1666; Leibniz you may recall is the co-inventor of "Calculus" and beat Isaac…

776 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