Evan,
you make a good arguement in the scenario you provide and I guess it boils
down to a design decision of which way to do. it may make sense to have all
opeation within one tx when the transaction is just touching 4-5
objects/entities and you don't want orphan records in your database
especially if part of your application will tend to display them as valid
entities.
> Here's another way of looking at this. Lets say for a moment that
> we have two kinds of transaction:
>
> (1) A business transaction.
>
> (2) A database transaction.
>
> Everyone seems to want to find ways of storing the uncommitted
> work of the business transaction as state within a session bean until
> the user says "go to it", and then have the session bean save changes
> to the database in a single database transaction. Thereby business
> transaction = database transaction.
>
> Long ago, before EJB and distributed transactions, back in the days
> of 2-tier and a single database, people solved this problem very simply
> by observing that one business transaction can be equivalent
> to multiple database transactions. You just need to apply a little
> thought when designing your DB schema.
>
> Let me explain with an example.
>
> In this case, a business transaction is a set of payments, all requiring
> a single receipt. For example, your city rates bill, plus your parking
> ticket plus your dog license will all be payed with a single cheque,
> (or ATM, or credit card) and a single receipt will be issued.
>
> So we create a new receipt entity in the DB, and set its status
> to "New". While the business transaction is in progress, we create
> a new payment entity in the DB for each payment, and associate
> the payments with the receipt (simple master-detail relationship).
> Note: each time we create a new receipt or payment entity in the
> DB we commit the DB transaction.
>
> When we want to commit the business transaction, we simply
> update the receipt entity and change its status to "Used", or
> some such. One hit to the DB, one record to update. Wow
> didn't that commit fast! I'll shop here agin, thanks!
>
> A system of this kind is in place in my city. It works well, and
> allows recovery and continuation of incomplete business transactions
> even after serious disruptions to the DB server, client failure and
> restart etc. Some of these transactions require many hundreds of
> payments on a single receipt. If you were to batch up all these
> changes as recoverable state in a session bean, when the time
> comes to commit your huge database transaction, you will
> possibly have serious problems with deadlocks and/or DB
> server response time (seconds may be too long, let alone minutes).
>
> Now, bringing this all back into the EJB world, I would suggest
> that you consider a design where the business transaction is
> equated to an instance of an entity bean. The final "done" or
> "commit" method on the bean commits the business transaction.
> Never mind that multiple DB transactions have been used.
>
> Two downsides to this approach:
>
> (1) You have to design your DB schema accordingly. Unfortunately
> this falls in the too-hard basket for many customers, especially
> the ones who are keen on session beans and entity beans with
> container-managed persistence.
>
> (2) You may end up with clutter in your DB, e.g. in the above
> example, old receipts from days ago with a status still = "New".
> You might want to clean these up or archive them occasionally.
>
> However you can now do some interesting data mining on the
> business transactions that were left incomplete, e.g. send
> follow-up emails to your potential customers.
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
