Win a copy of Rust Web Development this week in the Other Languages forum!

Chris Richardson

author
+ Follow
since Jan 10, 2006
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Chris Richardson

Hello,

A good first step might be to use iBATIS to simplify your code and move the SQL into external files.

JDO and Hibernate are roughly equivalent in terms of learning curve...

Chris
Eugene,

Thanks for the feedback. I will look into this.

Chris
Dave,

There are a couple of different ways to do this. If you are doing everything within a single database transaction then you can use database level locking as the Scott suggests.

However, the problem with this is that long transactions/holding onto database connections can limit the scalability of your application. This is especially true in web applications. Quite often a better approach is to use multiple database transactions: one to read the data and then another one to update the data (when the user saves their changes).

You then have to use application-level locking. There are two patterns: Optimistic Offline Lock, which is optimistic locking usually with a version number, across multiple transactions. See Fowler: http://www.martinfowler.com/eaaCatalog/optimisticOfflineLock.html. Alternatively, you can use the Pessimistic Offline lock pattern, where you implement an application-level lock. See http://www.martinfowler.com/eaaCatalog/pessimisticOfflineLock.html. My book describes these patterns in detail.

Chris

Originally posted by Harpreet Hira:
One of the features of EJBs that I admired the most was declarative transaction management. How are POJOs going to handle that?
Is the user manually going to use JTA or are we going to have some container who manages.
I guess I am still living in EJB world and the am out-of-sync with external world, which has gone past EJB.



The Spring framework provides declarative transaction management for POJOs.

Chris
Hello,

Unless you

(a) have a large number of columns
(b) have columns containing large values
(c) are accessing a large number of rows
(d) have identified performance problems

its unlikely that the overhead of returning all of a table's columns is significant.

Chris
Balan,

One way to look at the evolution of java frameworks:

0. No frameworks.

Your application code consists of a mixture busines logic + infrastructure logic (transactions, persistence etc) that you had to write yourself.

1. Invasive infrastructure frameworks such EJB 2.

The frameworks took care of the infrastructure issues (so you didn't have to write it yourself) but either (a) your classes had to implement special interfaces or (b) call framework APIs

2. Non-invasive frameworks/POJO-style programming

The frameworks still take care of infrastructure issues BUT very little of your code is coupled to those frameworks. For example, Spring provides transparent transaction management, Hibernate provides transparent persistence and only the small amount of DAO code has to call Hibernate APIs

Given all of the issues/benefits discussed previously I would claim that this is big step forward.

Chris
Hello,

A few comments:

1. One minor point: I think your bean is a persistent entity not a DAO. DAOs contain database access logic.

2. I believe a Hibernate SQL queries must be return all of the columns corresponding to the properties of the object. Since you SELECT does not return var3 you get this error "Invalid column name var3"

3. If you just want to populate a subset of the entity's properties you could use an HQL query that looks like this "select new Table(t.id, t.var1, t.var2) from Table t where ..". See http://www.hibernate.org/hib_docs/v3/reference/en/html/queryhql.html#queryhql-select

4. Another option is to use lazy property fetching: http://www.hibernate.org/hib_docs/v3/reference/en/html/performance.html#performance-fetching-lazyproperties

However, are you sure that you really want to do this. If Table is mapped to the database but you only need to retrieve a subset of properties then perhaps you should

5. Are you sure that you want to do this? Retrieving only a subset of an object's properties can be confusing unless you use option #4. Also, retrieving a non-persistent copy of your object (as your SQL query does or my HQL query in point #3 does ) can be confusing since updates to it will be ignored.

Sometimes it can be cleaner to create a DTO such as TableSummary that contains just the required properties and is not mapped to the database. It would be retrieved using "select new TableSummary(t.id, t.var1, t.var2) from Table t where .."

Chris
Eugene,

Thanks for your response.
It was very enlightening.

Yes, because chapter 3 is illustrating the TDD process it shows the initial and final versions of some tests. However, only the final version is compilable/runnable with the source code you can download. As far as I can remember thats the only place in the book that does that but I will check.

It sounds like you tried to copy and paste code out of the book rather just going directly to the downloaded source code (which compiles and runs). Is that correct? I hadn't expected that!

I will work on making the docs for the source code more helpful.

Chris
Scott,

If you want a self-contained example you might want to download the source code for my book. It uses maven2 as the build tool and so will automatically download all of the required Jars including HSQLDB (embedded Java DB).

Chris
Without seeing the the code, the Hibernate mappings, the query and the stack trace showing the error it is difficult to say that is going wrong.

Can you supply more information.

Chris
Only if makes sense in your object model.

Chris
John,

I posted a brief answer on EJB3 versus Spring/Hibernate on this thread: https://coderanch.com/t/216038/ORM/java/EJB

EJB3 is definitely a huge improvement of EJB2. So much so that I would readily use it. However, once you dive into the details you will encounter various issues:

* Spring's dependency injection is a lot more powerful and flexible, e.g. inject POJOs into POJOs, create objects via factory methods etc. In comparison, JEE dependency injection is limited to injecting JNDI objects into a fixed set of objects (EJBs, Web tier components such as servlets etc)

* EJB3/JPA object/relational mapping is less flexible than Hibernate or JDO's. e.g. lack of support for collections of non-entity beans; only limited support for preserving the ordering of lists.

* Session beans still need to be deployed in order to test them. EJB microcontainers do help with this though. In comparison, Spring beans are testable without any kind of deployment.

I write about these and other issues in chapters 1 and 10. The example code the book also includes some EJB 3 examples.

In summary. I think that Spring (and Hibernate) has a very bright future among developers who are not tied to using standards.

Chris
Jeff,

Which version of Hibernate are you using?
I am using Hibernate 3.1.
My example worked with a NOT NULL constraint on the position column.
I also looked at the debug output, which showed the insert specifying a value for that column. The UPDATE statement seemed to be gratuitous.

Chris
Eugene,

I am sorry to hear that you had a tough time with the sample code.

Unfortunately, you can only put so much code in the book and I wanted the downloaded source code to consist of realistic examples. I think its much more useful to have real examples rather than little snippets.

That is why the chapter 1 sample code consists of code and their tests. Similarly, the chapter 3 sample code shows the completed domain model and its associated tests rather than just the thin slice described in the book.

Having said that the downloadable code should be very consistent with the code in the book. In terms of class names etc. There should just be more of it.

One possibility is to expand the documentation for downloadable code to include a more comprehensive roadmap that would help you navigate it. e.g. The chapter 1 example consists of:
* Packages X, Y and Z - Java code that implements the business logic
* Packages A, B and C - Java code that implements the data access logic
* Packages P, Q and R - unit and functional tests
* Directory E - the Hibernate OR mapping files
* Directory F - the Spring configuration files that provide transactions and wire the components together.

Would this help? Please let me know. I want to find a way to make it as easy as possible. Send me an email if you would prefer to discuss this outside of the forum.

Chris
Jay,

I can't quite tell what you trying to do here but what happens if you

A. change each <list> mapping to:

<list name="collections" lazy="true"
cascade="all">
<key column="gcId"/>
<index column="lpos" />
<one-to-many class="billing.collections.GCCollection" />
</list>

i.e. remove the inverse="true" since I don't see the inverse relationship defined and remove the redundant table=".."

B. Either remove each:

<property name="lpos"/>

Or change each one to:

<property name="lpos" insert="false" update="false"/>

Hibernate will then maintain the list ordering in lpos.


Chris