Re: DAOs and Connection sharing

From: John Fereira (jaf30_at_cornell.edu)
Date: 07/31/04 

Date: Sat, 31 Jul 2004 13:05:58 GMT

janne_1976@hotmail.com (janne) wrote in news:6539de6f.0407300006.36ef1558
@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.

Relevant Pages

  • Re: How do you uniquely identify a connection in a connection pool
    ... Have you taken a look at the CLR Profiler? ... > will create as many as 25 new connections in the connection pool. ... the DAOs are in an assembly that is called by ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Container-managed Transactions scope
    ... In my case I am working on now, only one JDBC connection is ... The DAOs use this Connection to do their work but do not ... This method is being called from my EJB. ... >> the Container-managed Transactions be extended to the DAOs ...
    (comp.lang.java.programmer)
  • Re: How do you uniquely identify a connection in a connection pool
    ... Some approaches you can take to find which DAOs are not following the rules: ... Create a sql account and have it be the *only* account ... connection and you'll get an exception for those cases. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Container-managed Transactions scope
    ... Frankly, it's been a while since I mucked with JBoss configuration, but as I recall, in the servers I worked with the configuration information for each DataSource was in its own file in the server's filespace. ... If your DAOs all want to use the same Connection then you should pass them a Connection to use as a parameter to each method that needs one. ...
    (comp.lang.java.programmer)
  • RE: DCpromo issue. Health check on AD and group policy.
    ... new DC to create new inbound connection objects (You can't even via ... RAM / perf on most DC's, KCC was not autogening connection obj's. ... We have 2 DNS servers, Bart is the primary DNS server ...
    (microsoft.public.windows.server.active_directory)