article: Advanced DAO Programming

That's a very interesting article. Presently, I'm in a project that use something like 50 rmi objects, which use dao objects. Due to the nature of the project, the decision was taken not to use any of the j2ee app servers available. So I have to deal with JDBC transactions, RMI complexity, and project deadline!

Obviously, I encountered the problems with jdbc transactions that the article mentioned. I also experienced the bad decision to store a jdbc connection as an attribute of a RMI Server object, which is multithreaded and called quite often! The easiest way to solve this problem was to use JTA and a XADataSource from a naming service, but as I mentioned: -no app server, no transaction manager!

The pragmatic approach I used was to break a little bit my dao's design by passing a context as a parameter for each dao method. That's ugly, but it's the only solution I found. If someone know a better one for this case, please post!

fred-meyera at 2007-7-15 3:18:37 >

Hi,

I have a question here, Can I write my own transaction manager, for my own applications, will it have any boost in performance. I would typically uses array's and priciples around the array to get my job done. working this way will reduce the startup 'jar' files required to get my JDK up and running.

what could be the implications of doing things this way.

- kolly

kollyhooda at 2007-7-15 3:18:37 >

> This thread is old , but it came up in the search

>

> If the application uses only one Database (oracle) ,

> is it worth using JT A. Does it have an overhead?

You still have transactions with a single database. (I do when I perform write operations.) There's a difference between the vanilla JDBC driver and an XA driver for two-phase commit. Is that what you're asking?

You still use JTA for declarative transactions, even if you don't have two-phase commit.

> I can clearly see the advantage of avoiding a

> connection object parameter in the DAO's

Huh? How do you connect to a database without a Connection object?

> anyone , thoughts?

I didn't read the article. It is three years old, after all. So I'm not sure I'm following you here. What is it you want?

%

duffymoa at 2007-7-15 3:18:37 >

> Yes I know , But if you are using only db like

> e Oracle there is no need to do JTA right? ,

No.

> it can be done using JDBC driver.

In code, yes, but that's not declarative.

> Does JTA have a big overhead in this case compared to

> vanilla JDBC driver transaction control

So you've measured this "big overhead"? I don't believe you can quantify either the JTA or vanilla JDBC driver transaction control.

I'll promise you that performance problems will be caused by YOUR code, not these JDBC drivers.

> What I mean here is , if we have a transaction that

> goes across 2 different methods of a DAO or different

> DAO 's and if you are not using JTA , we have to use

> the same connection object to do the transaction

> control?

That's true whether you use JTA or not.

> if connection obj is created inside DAO , this won;t

> work , it has to be passed to the DAO methods as a

> parameter.

That's the first thing you've said that I agree with. This is correct. But who creates Connections in DAOs? I don't. The object that owns the unit of work should do that. In my applications that's the service layer.

> I understand that you can use JTA for declarative

> transactions without a 2-phase commit , but I am not

> sure about the overhead (if exists) that can be

> created by this .

I think you're crazy for worrying about this. Your code is far more likely to be a bottleneck that JTA.

Until you've profiled something and determined where a bottleneck lies, you have no basis for action whatsoever. You're guilty of premature optimization.

If you don't want to use a JTA driver, don't. Just understand what the real tradeoffs are for making that choice, not this imagined efficiency that you think you'll gain.

%

duffymoa at 2007-7-15 3:18:37 >

Duffy

Thanks for your valuable inputs

> > Does JTA have a big overhead in this case compared

> to

> > vanilla JDBC driver transaction control

>

> So you've measured this "big overhead"? I don't

> believe you can quantify either the JTA or vanilla

> JDBC driver transaction control.

I have not measured myself , bu found some article talking about the overhead it might/can cause ,so I was trying to findout if anyone here who knows more about this than me has seen the difference

> > What I mean here is , if we have a transaction

> that

> > goes across 2 different methods of a DAO or

> different

> > DAO 's and if you are not using JTA , we have to

> use

> > the same connection object to do the transaction

> > control?

>

> That's true whether you use JTA or not.

>

A lil confused here when you said that , how can it be true if we use JTA or not.

from what I understood from the docs is

JTA can control transactions over multiple connection objects

but

JDBC transaction control has to be under one connection object.

Correct me if am wrong

am_newa at 2007-7-15 3:18:37 >

> I have not measured myself , bu found some article

> talking about the overhead it might/can cause ,so I

> was trying to findout if anyone here who knows more

> about this than me has seen the difference

I'm not sure about the article. Send a link.

> A lil confused here when you said that , how can it

> be true if we use JTA or not.

> from what I understood from the docs is

> JTA can control transactions over multiple connection

> objects

> but

> JDBC transaction control has to be under one

> connection object.

> Correct me if am wrong

JTA can work with one or more connection objects, so it'll be fine for just one. JDBC works with just the one connection, but you have to define the unit of work in code. There's no way to accomplish it declaratively for a particular method or URL.

%

duffymoa at 2007-7-19 6:26:23 >