Hibernate vs Stored Procedure

1,363 views
Skip to first unread message

Kamran Saeb

unread,
Apr 11, 2013, 7:30:11 AM4/11/13
to jpos-...@googlegroups.com
Hi, all

Thanks for the hard work and I really appreciate the effort you guys have made till now.
I don't want to sound annoying, but I was wondering if hibernate is the best choice in such solutions with high volume transactions,
Do you guys think that using jdbcTemplate or pure jdbc with stored procedures would be a better option? or hibernate still remains fine?

Regards
Kamran
Message has been deleted

Mark Salter

unread,
Apr 11, 2013, 7:48:44 AM4/11/13
to jpos-...@googlegroups.com
On 11/04/2013 12:30, Kamran Saeb wrote:
> I don't want to sound annoying,
...

> but I was wondering if hibernate is the
> best choice in such solutions with high volume transactions,
It works for some, but perhaps not all?

> Do you guys think that using jdbcTemplate or pure jdbc with stored
> procedures would be a better option? or hibernate still remains fine?
How much 'better' do you find these approaches work over the existing?

I'm sure if options are available, then people can have a choice, are
your changes available for looking at?

:-)

--
Mark

Kamran Saeb

unread,
Apr 11, 2013, 8:15:12 AM4/11/13
to jpos-...@googlegroups.com
not yet really,
I think hibernate is good for large scale JEE applications where there will be frequent changes on tables and so on,
but how often do you get to change an acq table? I dont think much :D Honestly I like the integration with the c3p0 instead of having spring xml files, would it be awkward to use get the connection from hibernate and call stored procedures?
btw I took it from a post where Mr. Alejandro stated:
"db.session() gives you access to Hibernate's session, and if you just
need access to JDBC you can use db.session().connection();"
I can see the db.session()  method but I cant see the db.session.connection()?
I am doing some researches for now but if I get to a point where I decide to write unit tests I will post them here.

Thanks in advance,



--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage.
Please support jPOS, contact: sa...@jpos.org

You received this message because you are subscribed to the  "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users

---
You received this message because you are subscribed to a topic in the Google Groups "jPOS Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jpos-users/FY-oYDSqOms/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to jpos-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



Alejandro Revilla

unread,
Apr 11, 2013, 10:26:59 AM4/11/13
to jpos-...@googlegroups.com
I can see the db.session()  method but I cant see the db.session.connection()?

It's

db.session().connection()
          ^^

@apr

Victor Salaman

unread,
Apr 11, 2013, 10:51:05 AM4/11/13
to jpos-...@googlegroups.com
Hi Kamran:

We achieve "high volume transactions" today with Hibernate. When weighting the pros & cons between straight JDBC and Hibernate, please remember that we target many different database environments. Considering the performance overhead of using Hibernate as an object relation mapping tool is negligible for most typical use cases, the needs of many by far out-weight the needs of the few that want to over-optimize. 

This is an open source project and we welcome new ideas. If you can come up with a database portable, flexible and transactional way of accessing the database, that's 10 times faster than Hibernate, I certainly want to see it. Also, there is no stopping you in using jdbc in your application(s). The jPOS-EE setup just represent best practices, you're free to do whatever is best for your particular application.

Stored Procedures: Non-Portable
jdbcTemplate: Spring based, non-portable
iBatis: Lots of manual fumbling
NoSQL: Super nice, but just for a set of applications/use cases!

Just my 2 cents,

/V

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage.
Please support jPOS, contact: sa...@jpos.org
 
You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users
 
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.

Kamran Saeb

unread,
Apr 12, 2013, 6:01:27 AM4/12/13
to jpos-...@googlegroups.com
Hi Victor,

Thanks for the reply,
I think its all with respect of the environment and priorities, yeah right portability for an open source solution, but if we say we are facing just a specific RDBMS would you still say its the best practice to use hibernate, I'm pretty sure you guys have made various tests and I'm just asking if you've found hibernate a fast one?
Again would you pick hibernate if you have a specific RDBMS without a frequent change on it?
Thanks again,
Appreciated the help and time,

Regards,
Kamran



You received this message because you are subscribed to a topic in the Google Groups "jPOS Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jpos-users/FY-oYDSqOms/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to jpos-users+...@googlegroups.com.

Andrés Alcarraz

unread,
Apr 12, 2013, 10:17:34 AM4/12/13
to jpos-...@googlegroups.com
IMHO I always would use the most portable solution unless it becomes a bottleneck. Things doesn't change until they change. Other benefits are the more standard your solution is, The more likely you can get support in case needed.

That said if you feel more comfortable programming in the RDBMS store procedure language is valid, but in my experience it tends to complicate things later when you try to integrate with other parts.

regards.

And.


El 12/04/13 07:01, Kamran Saeb escribió:

Juan Pablo Torres

unread,
Apr 12, 2013, 10:29:50 AM4/12/13
to jpos-...@googlegroups.com
I think hibernate may create some overhead if your aplication use very complex joins or something like that. Where you can obtain some performance improvement by manually tuning your query.
That´s not the case of jpos. And the hole solution is very lightweight, stable and fast.
I don´t see any benefit on using store procedures. Plus the closest you are to the standard solution, the easy you can get help from the list.

Juan Pablo

chhil

unread,
Apr 12, 2013, 12:13:52 PM4/12/13
to jpos-users

My 2 cents
If you have a very specific product tied to a database then go for it. I have WO kid for a company that made products for a windows only platform and used jdbc with SQL tuned for a particular db and it worked well. Then came a period when adding support for db2 became important from a sales perspective, instead of going with an orm they went with a SQL converter a d they got the best of each db.
So the point is you do what's best for you.
-chhil

Kamran Saeb

unread,
Apr 12, 2013, 12:58:37 PM4/12/13
to jpos-...@googlegroups.com
Thanks everyone,

Do whats best for you is the solution :D

Regards,
Kamran


Sumeet Phadnis

unread,
Apr 13, 2013, 2:43:52 AM4/13/13
to jpos-...@googlegroups.com
Hi,

I have been working with stored procedures (Oracle) to a great extent in the past. Applications with high amount of business logic benefit from stored procedures, they are portable, efficient (as compared to implementing same logic outside database), deployment is easy. Also they scale with the database.

However one problem with stored procedures I have faced is version control. It is possible to change the stored procedures independent of the application, which can lead to issues.

Also, from my experience with jPOS / JPTS based applications, the database is used merely as a data store and most logic is in the code. There are rare "deletes", few "updates", many "inserts" and a lot of "selects". Hibernate with POJO classes works very well. For complex joins you can always use database views.

Good luck with whichever approach you choose.

Regards,
Sumeet

Kamran Saeb

unread,
Apr 14, 2013, 4:54:25 AM4/14/13
to jpos-...@googlegroups.com
Thanks for everyones advice ;)
peace


On Thu, Apr 11, 2013 at 4:03 PM, Kamran Saeb <kamra...@gmail.com> wrote:
PS: Speed is the first priority
--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage.

mona.ghol...@gmail.com

unread,
Oct 1, 2013, 3:16:56 AM10/1/13
to jpos-...@googlegroups.com
Hi, Kamran
I have same situation as yours and i wan't to know what you did after all and are you satisfied with your choice?
Since its been six month ago, i thought you may be done with your application till now and have a better understanding of the situation now.

Kamran Saeb

unread,
Oct 1, 2013, 4:04:23 AM10/1/13
to jpos-...@googlegroups.com
Hi mona,

I did go on with hibernate and I am very satisfied with the choice,

Regards
Kamran


--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage.
Please support jPOS, contact: sa...@jpos.org
 
You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users
 
---
You received this message because you are subscribed to a topic in the Google Groups "jPOS Users" group.
Reply all
Reply to author
Forward
0 new messages