Best Practice / pattern for coding for transactions

[js]

Is there a best practice / pattern for coding for transactions outside of an
J2EE container so that the code could be easily adapted to
Container-Managed Transactions ?

 

[richardsosborn]

I would think some of this would be done easily in Spring framework.
I haven't looked real close at their API for tranx, but it seems like
it would
be a good start.

Sun's forums and tutorials has some examples I think.

 

[Mark Jeffcoat]

I would think some of this would be done easily in Spring framework.
I haven't looked real close at their API for tranx, but it seems like
it would
be a good start.

I'm using Spring's transaction and JDBC management
on my current Big Project. It works good, but I'm
not sure it's compelling enough to recommend that
someone adopt the whole framework just for that.


(If someone asks nicely, I'll tell the story of the
home-brewed transaction management code written by an
earlier developer on this project, a Certified Java
Architect. Sadly, he'd made it through the certification
project (and xx years of experience) without actually
understanding what a transaction was, which made that
module a fabulous source of hilarious party stories.
Parties that didn't have quite enough girls and beer.)

 

[js]

I would think some of this would be done easily in Spring framework.
I haven't looked real close at their API for tranx, but it seems like
it would
be a good start.

Sun's forums and tutorials has some examples I think.

I can't really use Spring for now. There's still debate about it internally
here. Furthermore, a lot of non-Spring users "don't get it" straight
away ... The mindset has to be changed, and I think that the introduction
does not give it justice.

http://www.theserverside.com/news/thread.tss?thread_id=38767

 

[js]

I can't really use Spring for now. There's still debate about it
internally here. Furthermore, a lot of non-Spring users "don't get it"
straight away ... The mindset has to be changed, and I think that the
introduction does not give it justice.

http://www.theserverside.com/news/thread.tss?thread_id=38767

Just to clarify, I know that Spring has declarative transactions, ... but
has anyone gone from using Spring+Hibernate to moving the code to a J2EE
environment ( EJB 3.0 using Java Persistence ... similar to Hibernate ) ?

 

[Tom Forsmo]

(If someone asks nicely, I'll tell the story of the
home-brewed transaction management code written by an
earlier developer on this project, a Certified Java
Architect. Sadly, he'd made it through the certification
project (and xx years of experience) without actually
understanding what a transaction was, which made that
module a fabulous source of hilarious party stories.
Parties that didn't have quite enough girls and beer.)

Please share. Its always interesting to hear others use of technology,
because one might learn from it.

tom

 

[Mark Jeffcoat]

Please share. Its always interesting to hear others use of technology,
because one might learn from it.

I made the offer in a mildly mean-spirited kind of
mood. That having passed, I'll try to tell the story
with minimal sarcasm:

The Developer Who Almost Understood Databases


Once upon a time, I inherited a medium-sized Java project,
around 30,000 lines of code. After a few minutes of poking
around, I realized that 9,600 of those lines were in a
single class, the DataMaster. (No names have been changed
to protect anyone, as they started out generic enough.)

Every method in the DataMaster started and finished with the
exact same copy-and-pasted boiler-plate: The method would
open a new Connection to the database, do its own query and
update thing, and close the Connection.

Now, aside from being ridiculously verbose and slow, this
strategy worked. There were some odd bits of data corruption
here and there, but hey, Programming is Hard, and These
Things Happen.

In the course of ripping all this out, enlightenment struck:
Occasionally, one method in the DataMaster would call another.
Unfortunately, as both methods were using the same open/close
boilerplate, they were working in completely different Connections,
and the underlying database's transaction management was shielding
the one from the other's necessary updates.

Ooops.

Go ye and do not likewise.


(Readers are invited to draw their own moral from
this tale, and decide for themselves whether or not
my claim that the developer in question "didn't
understand what a [database] transaction was" was
justified.)