Transactional DB access without EJB

[Stan Sokolov]

What is a correct solution to implement persistent layer without EJB.
These are creteria:
- Transactional support - automatic transactional management.
- Flexibility and maintanability.
Is hibernate a good option ?

[Peter den Haan]

Without EJB at all? Can I recommend the "better, faster, lighter" Spring/Hibernate stack? We've been using this for a year on some chunky projects and it works very, very well. Hibernate gives you first rate O/R mapping. Spring gives you a first rate IoC/DI container, EJB-like declarative transactions (only better), Hibernate integration, and much more besides.

- Peter

[Stan Sokolov]

May you tell me what does IoC/DI mean ?
Our project does not have UI ? One year ago I read about spring. My impression was that this some kind of gambling with Event Handlers?
They also make something similar to Struts.
Does hibernate itself have transactional support ?

The simple use case looks like shown bellow

 
BEGIN TRANSACTION
//Read data 
Business Layer <- Data Transfer Oject <- Persistent Layyer Hebirnate <-DB
//Write data
Business Layer -> Data Transfer Oject -> Persistent Layyer Hebirnate ->DB
END TRANSACTION

[jake mu]

hey,
Why don't you go for JDO, it's very fast & light weight too.
If you don't have trust on it, thne try using "UserTransactional" interface with stored procedure.

cheers!

[Peter den Haan]

Originally posted by Stas Sakalou:
May you tell me what does IoC / DI mean ?

Inversion of Control / Dependency Injection. Where have you been hiding the last year or so

One year ago I read about spring. My impression was that this some kind of gambling with Event Handlers? They also make something similar to Struts.

Nothing to do with event handlers, and yes, there's a Spring MVC framework. But don't get hung up on that. Spring is more like a set of frameworks than a single monolithic one. In your case, I was thinking of the Spring bean container, its declarative transaction support (which builds on Spring AOP - don't worry about that AOP, it's based on simple JDK 1.3 proxies and really easy to use) and the Hibernate integration. You can simply ignore the rest.

Regarding JDO, I personally wouldn't choose JDO 1 over Hibernate but it would do a fine job as well. Would still recommend Spring.

Does hibernate itself have transactional support ?

It supports transactions, of course, but it doesn't allow you to declaratively specify transactional behaviour of business objects methods the way Spring, or for that matter the EJB container, will.

The simple use case looks like shown bellow

BEGIN TRANSACTION
//Read data 
Business Layer <- Data Transfer Oject <- Persistent Layyer Hebirnate <-DB
//Write data
Business Layer -> Data Transfer Oject -> Persistent Layyer Hebirnate ->DB
END TRANSACTION

Yep, standard stuff, it would fits the Spring/Hibernate stack like a glove; I haven't done anything else for the last year or so. The entire block of code between BEGIN TRANSACTION and END TRANSACTION would correspond to a single business method. With Spring, it takes one line of configuration or a single Commons Attributes attribute to specify the transactional behaviour of this method; all the types familiar from EJBs are supported and you get to specify the behaviour when exceptions are thrown too. The Spring bean container would be used to instantiate the business objects and DAOs, Hibernate session factory, look up data sources etc. etc. and wire them all together.

Believe me: after a week or two of this you won't want to go back to the way you used to work. By the way, if all you're used to is JDBC and/or CMP EJB, your biggest learning curve by far will be Hibernate.

- Peter
[ August 28, 2004: Message edited by: Peter den Haan ]

[Stan Sokolov]

2 jake mu
Hmm. I tried to make a simple search for JDO. It looks (for me) like there are a couple of framework implementations, one of them from Custor. Some of them are not free. It also was some feeling that it pretty much low level solution (at least comparing with hebirnate). Stored procedures from my point of view is bed option because they reduce portability . Just assume that I use My SQL - it does not have Stored Procedures at all. I am not using it know.But who know ?

2 Peter:
Gambling with Event Handlers = Hollywood principle that it uses (Don't call us we call you). It calls business methods in case of certain events. Methods do not call methods (at least it looks so for me).

So thank you for good advices. Probably one more question regarding DTO ?
Have you seen a tool to generate DTO objects using database schema ? It is very time consuming operation to create manually 400 objects with the same attributes as a db tables.

[Peter den Haan]

Originally posted by Stas Sakalou:
Hmm. I tried to make a simple search for JDO. It looks (for me) like there are a couple of framework implementations, one of them from Custor.

Castor JDO? Stay away from it. It predates JDO and is actually not a JDO implementation. A few years back it was ahead of the pack but it has remained almost static - Hibernate has comfortably overtaken it.

Gambling with Event Handlers = Hollywood principle that it uses (Don't call us we call you). It calls business methods in case of certain events. Methods do not call methods (at least it looks so for me).

Hollywood principle, yes, that's wat frameworks are all about. But for Spring this applies to application assembly and configuration only; you do call your business methods the oldfashioned way. It's not a message-passing SOA framework or event-driven framework or anything of the kind.

Have you seen a tool to generate DTO objects using database schema? It is very time consuming operation to create manually 400 objects with the same attributes as a db tables.

I personally prefer to roll my object model by hand, as it should generally not map 1:1 to the database schema. There are such tools in the Hibernate community, but I cannot really help you there.

- Peter

[Stan Sokolov]

I just have tried to download spring. Download screen offers Spring IDE for Eclipse. I like Eclipse but for daily usage I prefer jIDEA. Is it a big problem to work with spring without support from IDE ?

[Peter den Haan]

Originally posted by Stas Sakalou:
I just have tried to download spring. Download screen offers Spring IDE for Eclipse. I like Eclipse but for daily usage I prefer jIDEA. Is it a big problem to work with spring without support from IDE ?

Not at all. The most important thing the Eclipse plugin gives you is validation of the bean factory configuration file against your Java classes, which is nice, but not essential. The XML file format has deliberately been kept very simple. Any old XML editor will do.

I would suggest you explore the bean factory and application context infrastructure first. Then read the documentation on declarative transaction support; don't try to understand the AOP plumbing that underpins it straightaway. Have fun!

- Peter
[ August 29, 2004: Message edited by: Peter den Haan ]

[Stan Sokolov]

Guys if some of you tried to implement hibernate access without J2EE container.
My code should be run within scope of APP server. But for test proposes I have some simple tests that just call specific methods and should validate that everything is fine in general.

My goal is to make it possible to run junit (or other) tests without running a server. So the question is can I set DB properties for Hibernated without changing the code.

[Stan Sokolov]

I mean set properties of DB connections.
I run test it set some global config of hibernate and classes that request Hibernate session still work in the same way. Something similar is available for Log4J. If you run it within app server you just copy configuration file to the proper directory if you run it without J2EE server you have to specify path to the file.

[Stan Sokolov]

What I did to solve this issue is the following:
In the code that create Hibernate Session Factory, I just added configuration block that reads properties including mapping file name from a resource bundle and sets properties of Hibernate Configuration.

In this case hibernate must always use third party connection pooling (c3p0) mechanizm (not the one that is offered by App server) but it is ok for me at least for now.