Develop Reference

Performance of Hibernate or JDBC for write operations

I have a doubt if an application has more number of writes than reads, which performs better Hibernate or JDBC? .
My understanding is that for reads hibernate is fast because it uses cache mechanism. But for writes both are same as hibernate internally fires a JDBC query.
But there I am missing a significant difference between the two for writes
Kindly help me point out.

Hibernate is a layer on top of JDBC, so Hibernate will be at best as fast and in most case slower than a pure well-crafted JDBC application.
That being said hibernate performance are pretty good and more than enough for lots of project, the only real issue could be the start-up time with a lot of entity.

Design level query regarding Database access layer implementation for Java applications

Objective :
I want to design a DAO layer for may application , which will be used by web-applications and core java programs also.
Fist is it a good approach to have webservice for each database operation
(like : http://sometomcatappurl//insertEmp,updateEmp)
I am planning to configure connection pool in context.xml of tomcat
Access the data-source using spring , perform operation using jdbc template
I will use batch update in few places where i need to process requests in bulk.
The above URL will be call from various internal applications to communicate with database.
Per day requests expected 10-Million Inserts , 20-Million Updates, 20-Million selects.
Concern: Java, Tomcat , DB oracle and mysql are the technology constraints -
Which approach will be the fastest and salable way dealing with huge database operators.
Can spring handle huge requests, is it a good approach to have a web-service to perform database operations.
Note: I don't want to bloat my applications by writing database connection every where by accessing from a properties file, that is the reason going for context declaration with pool size.

A webservice works best for coarse grained transactions. If webservice is just a wrapper around a JDBC connection, you have only added overhead to the process. The webservice should represent a complete logical unit of work that either all succeeds or all fails.
In my experience, performance is 95% about managing the database. Spring adds overheads measured in nanoseconds per transaction, but using a column in a query on a table with a well tuned index that is not necessary can add 10 milliseconds to a transaction.
I am not sure what you consider "huge database operators". The workload you describe appears pretty mundane to me.
A good design that I have seen used to improve the scalability of systems is to put the business transaction processing (those that resolve to database inserts and updates) behind a webservice layer on dedicated hardware, which has the DAO and DSO layers embedded with in it. However, database selects for user display were run directly against the database to minimize the overheads. The DB server was scaled to handle the workload, running on a high SAN appliance.

Hibernate connection pool not working

I created one api using jsp and hibernate. I used this option of hibernate -
<property name="hibernate.connection.pool_size">50</property>
What I want is If I am getting 1000 hit concurrently on api then it should use only 50 connection not more than that. I thought above option of hibernate will help me to achieve this. But I tested my api on 10000 hit and I checked the open connection. It was around 3000. It means pool of connection not working.
How to get this ?

From the Hibernate documentation:
Hibernate's own connection pooling algorithm is, however, quite
rudimentary. It is intended to help you get started and is not
intended for use in a production system, or even for performance
testing. You should use a third party pool for best performance and
stability. Just replace the hibernate.connection.pool_size property
with connection pool specific settings. This will turn off Hibernate's
internal pool. For example, you might like to use c3p0.
Like mentioned, c3p0 is a good option.

converting sessions in hibernate to plein JDBC connections

I am shifting back from hibernate to plain JDBC in order to overcome the overheads incurred in using hibernate.I wanted to know how to deal with the sessions associated with hibernate.How should i convert back to Plain JDBC so that all my sessions are replaced with the JDBC connections.And please let me know if I am wrong in my thoughts that replacing a session with a connection converts back to plain JDBC as I am not well versed in these concepts and dont know if i am going in the right way.

I have used Hibernate extensively in high-performance tasks, including batch insertion of millions of records. Your problem is not with Hibernate, but with the way you are using it.
Above all, do not use Hibernate as a persistent state manager; use it as a thin layer above the raw SQL and you won't complain about performance.
Always prefer StatelessSession (it works for everything you need except save operations)`;
never use lazy fetching, use explicit joins for everythng;
never fetch whole objects, use SELECT to fetch exactly what you need;
fetch as much as possible in a single statement, avoid n+1 selects at all costs;
for large result sets, never use list, use iterate or scroll.
The list goes on, but this is what I have come up with at this moment.
As far as your direct question, it depends on the application. If it is a Spring application, then you will certainly want to use its declarative transaction management. Basically, you just put a few lines of XML config and you'll have an open DataSource in your DAO code ready to be used, with no management on your part.
If you are doing something more raw, then by all means use a connection pool library, such as the great BoneCP. You acquire connections from it and later return them to it, again with no explicit management.
Lastly, if you really want a bare-bones, unsafe and non-scalable approach, then you can create connections directly from the JDBC driver. This approach is really only for schoolwork and it is not recommended even in the smallest of production-worthy projects.

A Hibernate session is much more than a JDBC connection. It contains multiple such connections (usually managed via a JDBC Connection Pool which recycles JDBC Connection instances), a bunch of entities which are attached to, and managed by said session and other things as well (caching, etc).
Removing Hibernate and doing everything with the JDBC API-only will imply more than just replacing Hibernate Session instances with one or more JDBC connections followed by a duplication of the Hibernate code into analogous JDBC API calls. If you'd only do that, you'd simply do a lot of work for nothing, as you'd lose all of Hibernate's advantages (less verbose code, a higher level of abstraction, etc) and gain nothing of JDBC's advantages (less heap memory used, fewer method calls (yes, even with Hibernate's Javassist magic, this still counts towards performance in some cases), finer grained control of the database interactions, etc).
My advice is to first really look into the problems your app has (apparently due to Hibernate) and at least for the major ones, try to first see if you can't do something to optimize it without getting rid of Hibernate. Yes, Hibernate can become heavy and memory hungry, but more often than not, the issue with performance comes from improper use of the framework (are you sure you're fetching all the necessary associated entities in one query, or do you make Hibernate make hidden joins or pseudo joins in the background? Are you doing or you data operations on the database side, or is some of that done in Java code after a more-than-necessarily-generic Hibernate query is executed to fetch the data? etc.)
If you really need to get rid of Hibernate (maybe you need to use some very specific features of your database which are not standard SQL and which Hibernate doesn't let you access, like MySQL's ability to import big amounts of data via a custom flat-file format) then make sure that what ever it is you're replacing it with (plain JDBC, or maybe some other ORM like EclipseLink) can tackle the issue and solve it in a more performant way. Doing a small POC to test these before you start re hauling your code can save you a ton of time.

While I strongly urge you to heed the advice of Marko and Shivan, you could use hibernate to manage your connections/sessions/transactions and to execute your SQL queries without much overhead being generated.
a quick google search yielded this on executing SQL from a hibernate session.
http://www.informit.com/guides/content.aspx?g=java&seqNum=575
While I agree with both of the earlier answers, if you truly want to go down the road of executing straight SQL, I would look into this option for two reasons.
1) your sessions are already in place. If you don't have hibernate load up all of your entities I don't see how hibernate would generate that much overhead.
2)If the problem is speed, and not overhead which I have run into before, you can implement this to quickly execute native SQL in your problem areas and keep all of hibernates ORM goodies in place.
All of that being said, I would also urge you to dig into the documentation for hibernate. I have used hibernate for several high performance solutions with great success. While the nuances can be hard to grapple with in the beginning, the benefits of using hibernate (or at least something that adheres to JPA standard) far outweigh the cost of not doing so down the road scalability wise.

Connection pooling in hsqldb

What is the best way to implement connection pooling in hsqldb, without compromising on the speed?

Hibernate gets connections from a DataSource, uses them and closes them. You need a connection pool or it will be very inefficient, consuming a lot of resources both on your app and on the DBMS, regardless of the database server you use.
You should try out commons-dbcp from Apache-Jakarta, it's very efficient and really simple to set up. It depends on commons-pool.
You just define a BasicDataSource with DBCP and it will manage the connections from whatever JDBC driver you tell it to use. It has connection validation and lots of other stuff.
Of, if you're writing a web app, configure a connection pool on the container you will be using and use that, instead of defining your own pool.

You are comparing apples and oranges:
If you want orm compare the performance of different orm tools against the same db.
If you want connection pooling compare different connection pooling libraries against the same db.
Performing ORM incurs extra effort so it will never be as fast as direct JDBC access. That said, hibernate goes to great lengths (and very successfuly) to minimise this additional overhead. With ORM you are trading off significantly increased development productivity against a relatively small drop in performance.
Connection pooling is an orthogonal problem to orm. Most obviously, hibernate allows you to select your own connection pooling infrastructure.
Also, be aware that in practise there is often a fairly tight coupling between connection pooling and transaction mgmt. For example, a typical J2EE application will leave connection pooling to the container (via the JDBC Datasource API) and rely on declarative transactions. In this case connections and transactions are managed (approximately) together.
If you aren't in a J2EE container and you don't need orm I would simply compare C3P0, commons-pool, etc.

If you used Hibernate's own connection pooler, you could consider using c3p0? (If you're already using c3p0, I can't help further) I haven't used HSQLDB myself but I think that could be worth trying.