Valentin Tanase

Ranch Hand
+ Follow
since Feb 17, 2005
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Valentin Tanase

Hi Jay,

Have you defined a pk for your TestVO?

Hi Adnan,

This is not a clustering issue and it probably has more to do with stale data. This could happen for example if you�re using graphs of objects when modeling parent-child relationship. Supposing you have an item that has a list of bids and you change something about the item and save the item only, hibernate will also try to save the list of bids (if the relationship�s cascade attribute is set accordingly). On the other hand if another transaction would alter any of the bids within the collection then Hibernate will issue a StaleDataException, which I�m only guessing is wrapped by this HibernateOptimisticLockingFailureException spring runtime exception.

I hope this will help.

Hi John,

Actually it is possible. See the Glue code and the evil singleton chapter at the bottom of the page:

Hi Hector,

Let me see if I understand your problem correctly: you have several beans A, B and C defined within your Spring config files (via dependency injection). At run time you need to load either those classes (via reflection) or at least another class D that makes use of these beans (D also uses DI for referencing A, B and C). If that�s the case then I should make you aware about at least one design decision that you might reconsider: because you�re violating the DI pattern probably spring is not the ideal framework to use with your project.
Having said that you still can overcome the issue you�re facing. However it will require little bit more refactoring and use the glue code pattern that Spring recomands for solving this kind of problems. You could read more here:

Finally I�d suggest you writing a new class that uses the "glue code" for loading the spring beans and finally have this class loaded via reflection. I personally did that seceral time to integrate frameworks that are not spring-aware and I�m personally using the org.springframework.context.access.DefaultLocatorFactory class:

You're very welcome Gavin , I'm glad I could help.
Hi Gavin,

First and foremost please make sure that you don't have a typo within your jsp:

Nevertheless if your __itemModel__ is kind of a __Map__, the code above should definitely work. This because you�re using JSTL, which in turn implements and supports the EL (expression language).
Another elegant solution that you could use as well is to override the __referenceData__ method. This will return a map of beans (name-value pairs), which will be bounded to your page within the page context.

Same idea: try aspectj or other aop framework and use aspects (this also could be specified via configurations) in order to benefit of declarative transaction management. AOP by the way is mainly used to address this type of cross cutting concerns and you could use it very successfully for logging, debugging, etc as well.

Hi Varun,

1->I want to know if hibernate supports declaritive transaction management .

The answer is no: Hibernate by itself doesn�t support declarative transaction management. However there is a very nice and elegant solution to this problem: use Spring and Hibernate and you�ll be able to take advantage of Spring AOP to achieve this goal. There probably will be a little more abrupt learning curve, but once you passed that point you�ll discover that not only Spring integrate very nicely with Hibernate, but it will actually simplify the development and configuration management of Hibernate application quite a bit.

2->If yes does this declaritive transaction management depends on JTA and a supporting Application server .

Not really. Assuming you�re using Spring with Hibernate you could plug any type of transaction manager, including JDBC, JTA or even a Hibernate specialized one (there are also couple more for CORBA OTS, etc).

Can I use Tomcat for declarative transaction management with Hibernate .

Again assuming you�re using Spring and Hibernate, then yes you can. That�s another benefit of this architecture over the ejb3 for example: you�re not depending upon the heavyweight containers anymore.

Is hard to say what design pattern you should use without knowing what problem you actually trying to solve.
However I can give you an idea about your application�s architecture: use Spring as the lightweight container and Quartz as the scheduler and you�ll be able to schedule tasks without running any piece of code. Almost everything could be done through configurations only (no need to use unix crons, Quartz resembles the same syntax).

Second use dependency injection to develop your beans (pojos) and if you follow the ioc paradigm closely with little effort you should be able to deliver testable and easy to maintain code (please notice that there is always a difference between designing a class and designing a testable class). And because you like using design patterns remember about the strategy design pattern (when develop your pojos).

Third use jMock and jUnit in order to fully test and cover your code. For running coverage reports on your code you could use either clover or cobertura. If you apply the strategy design pattern to your pojos you should be able to "inject" mock objects at runtime in order to build test cases that don�t really depend upon any external systems.

Fourth enable PMD and checkstyle when writing code in order to deliver high quality code.

This is probably a lot of work to do but at the end you�ll feel like doing the right things right.

You�re very welcome Kumar.

I personally started with Spring in Action by Craig Walls and Ryan Breidenbach and I found it really, really good. It�s very well written and explains everything very well. It�s a good book for beginner as well as more advanced Spring users. Another very good source is the online documentation:

As for the newly released ejb 3.0, I�m not sure if anybody knows for sure what�s going to happen. We can only guess though and I�ll tell you little bit of my experience. In last couple of years I worked for two pretty big corporations in USA and I got the opportunity to meet with really bright and senior people. They all "confessed" that they�re not doing ejb development anymore and are looking forward to see some of their new applications deployed on tomcat. Other, which are still managing old legacy ejb projects also "confess" that they�d whished to never start their projects using ejbs. My opinion though is that there is a growing feeling within the j2ee community that ejb really screwed things up. Besides unlike seven years ago we have good choices (and already proven to be good!) to choose from. It�s a shame though but the big guys have been severely beaten by a handful of developers, many of them working for free as a free open source community.

The actually reason I don�t give much chances to ejb 3.0 to take over is because the big guys will never change their monolithic, oligarchic way of owning and releasing software. As an example look at jdk itself: I got certified with jdk at the end of 1.4 in 2004, when jdk 1.5 was on the verge. And what a release� Never got a chance to touch 1.5 and never seen anything like 1.6 in my life. And what is the latest jdk release? 1.7?! In less than three years? You must kidding me! And they all used to blame Microsoft for this kind of oligarchic approach...
Here there is my two cents bet: the ClassPathXmlApplicationContext also implements the BeanFactory interface. This makes the point that after initializing the app context this class will also load all beans from the configuration file(s). By default these beans suppose to be singletons (unless you specify otherwise). I would say that you�d have two different bean factories instances, loading the same beans. Just for the argument sake you can try running this code:

Where "beanName" is the name of one of your beans as it appears in the config file. This should also be loaded as a singleton (default).

And again just for the argument sake: I personally could not see any treason or benefit from having two different bean factories.

You're very welcome Abhishek.

PS I've been through both heavyweight and lightweight development for a while now. Sometimes is not that you could chouse and you have to do what you have to do 'cause either one should pay for the bills. However if you really have the privilege to chouse between the two, then don't hesitate and go with the lightweight development. Believe me the difference is immense.

You're very welcome Gavin.

I suppose that you'd like using declarative transactions (via AOP) with Spring. You may need then to read about the Spring transaction management here:

In a nutshell you need to define your transaction manager to be JTA compatible. If you�re using WAS it might look something like this:

For most of the app servers using only the JtaTransactionManager should be quite enough.

Now assuming you have a controller bean that uses a DAO (implemented using an ORM tool like Hibernate) that updates two different databases, which should happen within the same transaction:

The trick here is that you�ll map the requests to a proxy bean ( removeTransactionController), which will actually do the transaction management for you (Spring uses the cglib api in order to build this proxy bean at runtime):

If your app doesn�t use global transactions, then using the HibernateTransactionManager could be your best choice with spring-hibernate applications:

Basically this is how it works.