Author |
Message
|
sugan87 |
Posted: Fri Jul 29, 2016 2:24 am Post subject: ODBC VS JDBC Performance |
|
|
Novice
Joined: 14 Jul 2016 Posts: 18
|
Which is best performer, compute node with ODBC connection or Java compute node with JDBC CONNECTION?
Last edited by sugan87 on Sun Jul 31, 2016 10:30 pm; edited 1 time in total |
|
Back to top |
|
|
Vitor |
Posted: Fri Jul 29, 2016 4:17 am Post subject: Re: ODBC VS JDBC Performance |
|
|
Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
sugan87 wrote: |
Which is best performance performer, compute node with ODBC connection or Java compute node with JDBC CONNECTION? |
Depends entirely on what you're doing with the connection. There's no simple answer.
Having said that, the DataDirect wire drivers inside the ODBC connection will outperform most Type 4 JDBC drivers for most common operations. In the same way ESQL will outperform Java for most common transformation operations.
That's still no good criteria for picking a Compute node over a JCN. There are much more compelling reasons why you'd pick one over the other.
I would also assert that if the difference in performance between one or the other is that critical to your solution, you've got a problem with your design or your SLA. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
|
sugan87 |
Posted: Fri Jul 29, 2016 5:05 am Post subject: |
|
|
Novice
Joined: 14 Jul 2016 Posts: 18
|
Thanks vitor,
we are in a design phase, selecting the nodes and integration points on that which is best approach on performance vise. we have lot of DB integration in our message flow. So, thinking of use Compute node (eSql) to call the JAVA method to connect database using JDBC Connection. We are believing JDBC as a good performer compare to OCBC.
eSQL(Compute Node) ----> Java Method -----> JDBC Connection.
Please share your thought....
Last edited by sugan87 on Sun Jul 31, 2016 10:29 pm; edited 1 time in total |
|
Back to top |
|
|
smdavies99 |
Posted: Fri Jul 29, 2016 5:10 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
Quote: |
eSQL(Compute Node) ----> Java Method -----> JDBC Connection.
|
Do not do this. You will probably bring a whole lot of grief onto your project.
This is even worse than using a JCN + JDBC.
ESQL Compute nodes use ODBC. There are thousands and thousands of flows processing billions of transactinos a day using ESQL Compute nodes.
They work. Why do you want to re-invent the wheel as a hexagon? _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
|
sugan87 |
Posted: Fri Jul 29, 2016 5:19 am Post subject: |
|
|
Novice
Joined: 14 Jul 2016 Posts: 18
|
Thanks smdavies,
So, your saying ODBC gave good performance than JDBC. Can you able to share some point about ODBC and JDBC performance stands in DB access. |
|
Back to top |
|
|
Vitor |
Posted: Fri Jul 29, 2016 5:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
smdavies99 wrote: |
Quote: |
eSQL(Compute Node) ----> Java Method -----> JDBC Connection.
|
Do not do this. You will probably bring a whole lot of grief onto your project.
This is even worse than using a JCN + JDBC. |
That is the worst of all possible worlds.
smdavies99 wrote: |
ESQL Compute nodes use ODBC. There are thousands and thousands of flows processing billions of transactinos a day using ESQL Compute nodes. |
I repeat my comments above regarding the difference in performance. If you're that desperate to get the few milliseconds by which a JDBC driver outperforms the ODBC driver (note I don't say "connection", both are using the same piece of wire to reach the db server) then something is very badly wrong.
I would also point out that you're likely to lose any performance gains in the solution you've outlined as it hops and skips through memory from ESQL to the JVM and out.
Aside from the many, many other issues with doing what you propose. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
|
Vitor |
Posted: Fri Jul 29, 2016 5:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
sugan87 wrote: |
So, your saying ODBC gave good performance than JDBC. |
No, IBM installed ODBC into IIB years ago as a joke and we're just trying to keep you in the dark.
sugan87 wrote: |
Can you able to share some point about ODBC and JDBC performance stands in DB access. |
Why are you so obsessed with db performance when by your own admission you're still in the design phase? Badly written code (in any language) is more likely to affect flow performance than anything you do with a database. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
|
sugan87 |
Posted: Fri Jul 29, 2016 5:41 am Post subject: |
|
|
Novice
Joined: 14 Jul 2016 Posts: 18
|
Thank you guys,
There is an discussing going, which is best ODBC or JDBC connection. since my account JDBC is a know devil than ODBC. So, there is an obsess to select Compute node with ODBC.
I have understand that Compute node and ODBC are IIB proprietary language. so, definitively will give good performance than others.
Last edited by sugan87 on Fri Jul 29, 2016 5:45 am; edited 1 time in total |
|
Back to top |
|
|
Vitor |
Posted: Fri Jul 29, 2016 5:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
sugan87 wrote: |
my account JDBC is a know devil than ODBC. So, there is an obsess there to select Compute node with ODBC. |
Be aware that IIB is not WAS. It does not handle Java, JDBC or any other artifacts the same way. One good (and possibly relevant) example is the amount of discussion on this forum about JDBC connection pooling in IIB, and how it differs from WAS connection pooling.
The Search Facility Is Your Friend. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
|
sugan87 |
Posted: Fri Jul 29, 2016 6:07 am Post subject: |
|
|
Novice
Joined: 14 Jul 2016 Posts: 18
|
Thanks all for your valuable replies. |
|
Back to top |
|
|
fjb_saper |
Posted: Fri Jul 29, 2016 8:26 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003 Posts: 20729 Location: LI,NY
|
To help you choose between ODBC and JDBC you should also think about the requirements of your flow and any transactional boundaries needed. JDBC in IIB has some restrictions on transactional boundaries... _________________ MQ & Broker admin |
|
Back to top |
|
|
sugan87 |
Posted: Sun Jul 31, 2016 10:27 pm Post subject: |
|
|
Novice
Joined: 14 Jul 2016 Posts: 18
|
Thanks fjb_saper,
Can you please brief about restriction in IIB transaction boundary. |
|
Back to top |
|
|
fjb_saper |
Posted: Sun Jul 31, 2016 11:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003 Posts: 20729 Location: LI,NY
|
sugan87 wrote: |
Thanks fjb_saper,
Can you please brief about restriction in IIB transaction boundary. |
Look it up, it's all in the infocenter. _________________ MQ & Broker admin |
|
Back to top |
|
|
sselva86 |
Posted: Tue Aug 02, 2016 12:19 am Post subject: |
|
|
Novice
Joined: 25 Oct 2010 Posts: 17
|
instead of calling java method from compute node why cant you use java compute node itself and connect JDBC . when using JDBC be cautious with JVM if you are going to use huge number of transactions . ( JDBC is your know devil )
As experts said before ESQL with ODBC works well and processing huge number of records when you handle the connections properly .
Performance between these two is mainly relies on how you are coding ESQL/JAVA . |
|
Back to top |
|
|
zpat |
Posted: Tue Aug 09, 2016 5:38 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001 Posts: 5856 Location: UK
|
JDBC drivers don't come with IIB. This means that people grab some jar from somewhere, and then it will get left behind over the years and be out of date also no-one will want to update it in case it breaks something.
Whereas IBM will ship updated ODBC drivers with each release of IIB, which have been tested with that version of IIB.
Always use built-in features in preference to external JAR files. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
|
|