>
>>
>>As mentioned elsewhere, getting a database connection from the web tier
>>is not a good practice. The Struts framework does try to encourage best
>>practice but sometimes takes a dip in the pool of pragmatism. The
>>Generic Connection pool is one example of this. The data access objects
>>should take care of all the connection stuff and just pass back standard
>>Java objects like JavaBeans and Collections. The web tier, and even
>>business tier, does not need to know where the data comes from.
>>
>
>If the data access objects completely encapsulate the connection stuff,
>how does the business object wrap two calls to the data access layer in
>one transaction? Take for example the well-worn credit and debit
>financial transaction. Would you wrap that up into one data access
>object and say OK, we've got two operations rolled into one and we can't
>seperate them and re-use them, but that's necessary for a transaction?
>
>On the other hand, if the data access objects are handed the connection
>by the business object, or if the connection came from the struts
>connection pool, then the transaction could be handled easily I know. Am
>I chasing a Holy Grail here?
I believe it may be worthwhile to separate transactional considerations
from data access object design. If you need to manage transactions across
multiple database updates, then consolidating all your data access code
into a single DAO is only one way to handle it.
Once you get to the point of needing to manage transactions across multiple
data access objects, it may be worthwile to use an EJB Server (JBoss is
free after all if cost is the issue). Then you can just grab a
UserTransaction to wrap whatever code you want in the web tier and use the
ejb server for managing the transaction details. Then your DAO design
doesn't have to be impacted (as much) by your to manage the transaction.
The other issue is the granularity of the Data Access Object. These can be
fairly coarse-grained and handle updates/transactions across multiple jdbc
connections even in the web tier.
For example, in your example you could have something like:
/*
* handle the debit/credit transaction
*/
UserAccountDAO ua = new UserAccountDAO(userID);
try {
ua.beginDAOManagedTx();
ua.processDebit();
ua.prcessCredit();
ua.commitDAOManagedTx();
} catch (DAOApplicationException e) {
ua.rollbackDAOManagedTx();
}
In this situation the DAO could somehow manually handle the transaction
internally and just throw a DAOApplicationException if problems arise.
I guess what I'm saying is "there ain't no holy grail". All you have is
trade-offs between cost, quality and schedule and you do your best.
Different solutions may be better depending on the project and where you're
at...
As they say in Perl, TIMTOWTDI - there's more that one way to do it...
>
>Adam
>
FWIW -
Kevin
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
