DAOs and Connection sharing

[janne]

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.

Hibernate and other alternatives are all very nice, but I want to
concentrate on this kind of approach now...

 

[Dave Glasser]

(e-mail address removed) (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.

 

[John Fereira]

(e-mail address removed) (janne) wrote in @posting.google.com:

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.

Hibernate and other alternatives are all very nice, but I want to
concentrate on this kind of approach now...

Have you looked at the Spring Framework? www.springframework.org
I've written an application similar to what you're suggesting and the Spring
Framework manages the Datastore and DAOs nicely.