I am currently looking at an application that uses a large number of BMP for data persistence. The stateless session facade looks like a structural code and workflow methods looks like C. On top of this we are experiencing a certain degree of performance issue due to the need to persist all the data (especially CLOB data type)

I am looking at Hibernate as an elegant alternative to the current architecture where I could persist POJO directly (Assuming I dont run into myriad of db mapping issues).

However from performance perspective I was wondering would hibernate offer any significant performance improvement over BMP for a most Create/Update intensive application.

I google'd and also looked at this forum and couldnt find any convincing answers to my pointed question.

Any response addressing this question would be great.

Thanks, ~vk

I don't think anyone is going to claim that Hibernate is always faster than BMP without knowing anything about the application.

That said, I'm working with an application that is has mosty SSBs with Hibernate (a few entities as well, but they are all read only). With regards to performance, I found Hibernate easier to tune for performance (cacheing, etc.) than the straight JDBC BMP that I had used before.

Also, using Hibernate also allows a design that has coarse-grained entity EJBs (recommended) for the clients, while simultaneously allowing fine grained POJOs for the SSB implementations. This avoids the 'too many entities in a transaction' anti-pattern that many teams face when first implementing an EJB-based application.