Re: DAOs and Connection sharing
From: Dave Glasser (dglasser_at_pobox.com)
Date: 07/31/04
- Next message: ak: "Re: Certified Java Programmer (Sun Java 2)"
- Previous message: PC: "Certified Java Programmer (Sun Java 2)"
- In reply to: janne: "DAOs and Connection sharing"
- Next in thread: John Fereira: "Re: DAOs and Connection sharing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 31 Jul 2004 08:04:38 -0400
janne_1976@hotmail.com (janne) wrote on 30 Jul 2004 01:06:24 -0700 in
comp.lang.java.programmer:
>I have been using a DAO -based design to implement my applications
>with the following principles:
>
>- business / persistence logic is handled by 3 layers; Actions,
>business logic classes and DAOs
>- logic in a use case is handled by an Action (Struts is not used; but
>for the sake of discussion you might as well assume it is)
>- Action gets a Connection from a DataSource; and passes it to each
>business logic class it uses
>- When persistence is needed, business logic class calls a DAO and
>passes it the Connection. All database activities therefore share the
>same connection and transaction.
>- After Action is finishing, Action either commits (if no exceptions
>were thrown) or rolls back (in case of exceptions) the connection, and
>closes it.
>
>This works fine, but there's coupling between
>actions-business-persistence with the passed Connections. I have seen
>suggestions that an alternative approach could be used:
>
>- Connection objects are not passed as method arguments. Instead each
>DAO fetches Connections from DataSource directly
>- I would still use Action to commit / rollback the whole transaction
>
>The basis for this, according to some, is that when different objects
>in same thread request connections from a datasource, they in fact get
>the same shared connection. Which is a requirement for this to work,
>of course.
>
>Does this work, and if it does, can you point to a specification that
>describes DataSource's correct behaviour? I have not been able to find
>any.
>From the DataSource Javadoc:
The DataSource interface is implemented by a driver vendor. There are
three types of implementations:
1. Basic implementation -- produces a standard Connection object
2. Connection pooling implementation -- produces a Connection object
that will automatically participate in connection pooling. This
implementation works with a middle-tier connection pooling manager.
3. Distributed transaction implementation -- produces a Connection
object that may be used for distributed transactions and almost
always participates in connection pooling. This implementation
works with a middle-tier transaction manager and almost always with
a connection pooling manager.
So the answer is, it depends on which implementation you're using. It
seems to me that, in order to achieve what you want, you'll have to
implement some sort of custom Connection factory. Internally, it might
use a java.lang.ThreadLocal object to associate a single connnection
with a single thread, but you might even have to implement that
functionality yourself, since ThreadLocal would not let you
*disassociate* a Connection from a particular thread.
- Next message: ak: "Re: Certified Java Programmer (Sun Java 2)"
- Previous message: PC: "Certified Java Programmer (Sun Java 2)"
- In reply to: janne: "DAOs and Connection sharing"
- Next in thread: John Fereira: "Re: DAOs and Connection sharing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
