• Post Reply Bookmark Topic Watch Topic
  • New Topic

native methods  RSS feed

 
Jay Brass
Ranch Hand
Posts: 76
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey there,
I have a JAVA application that hooks up with a database among other things. I have to do several various types of lookups on this database. Could I gain anything by writing a native method ( in C++ or even assembly) to connect and run my select statment? Depending on what information is needed I may need to connect with another database or query another table within the same database. I know I could put indexes on the tables to speed up that end (but that is probably better discussed in some place like Oracleranch) I guess my question is: is it worth exploring native methods for this application and should I limit their use? and how much overhead does the JNI add?
any help thoughts or criticism is welcome.
Thx
J
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JNI imposes additional overhead, and it significantly reduces performance especially in graphics and I/O. This overhead, is a compromise you make inorder to achieve VM-independence.
JNI is sometimes called "overhead incarnate". It's well known that a Java-->C or Java-->C++ invocation is four to five times more expensive than a Java-->Java invocation. As a result, JNI code is only fast if few actual invocations have to be made; that is, if you can batch your C/C++ calls together and perform a whole bunch of operations with a single callout to C. Writing code this way is quite ugly.
Of course, I certainly encourage people to prove me wrong
------------------
Ajith Kallambella M.
Sun Certified Programmer for the Java2 Platform.
 
Jay Brass
Ranch Hand
Posts: 76
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ajith,
I guess then staying with JAVA is better. Do you have any thoughts on setting up a connection pool to connect with different DB's? Or does that create overhead of its own?
thx
J
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just a few thoughts.....
If anything, Connection pools certainly help object reuse and resource optimization. It is nothing more than an extension of object-pooling strategy where frequently accessed "expensive" objects are not discarded after use, but recycled.
Connection pooling is a good strategy if establishing a DB connection turnsout to be a time-consuming operation. Consider for example a multi-tier architecture where your app server( tier 2 ) is on a different box than the DB( tier 1 ). Here establishing a DB connection would involve some network traffic and a latency. If for every client request( from tier3 ) you have to connect to DB and process the request, discarding the connection after completing the request may not be a good idea. This scenario is an ideal candidate for using connection pooling.
On the otherhand, if you only had a limited ( and significantly ) number of clients and/or the application is based on a 2-tier architecture with the appserver and DB residing on the same machine, and/or if your network is fast so that latency is almost minimal, connection pooling might prove to be an overkill approach.

------------------
Ajith Kallambella M.
Sun Certified Programmer for the Java2 Platform.
 
Marius Holm
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I don't know so much about the concept 'connection pooling'. It does, however give an immediate association of 'connections in a pool' that I assume to be correct.
My experiences with connecting to DB's are not with Java, but I find that whatever way I do this, the app halts for a while when doing queries, no matter if the DB is on the same machine or on the network. I have not done so much probing into how the time used is divided in connecting and the query itself, but my firm belief is that the more you can do away with in initialisation or while waiting for something else, the better. In your scenario, if there is no reason not to, I would certainly try to make the connection(s) before 'the show starts' and keep them ready for when you need them. Also, if there are some queries that are very likely to done, you can do them to, if data doesn't change to often, and just program a flag for when to re-query. These kinds of tricks can improve overall performance quite a bit, even though DB connecting and query proceeds with the same speed as before.
Good luck,
Marius
 
Jay Brass
Ranch Hand
Posts: 76
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thx Guys,
Yeah it will be a 3 tier architecture. And yes, some of the queries will be redundant. Marius, I like the "flag" deal for when to re-query. I guess I'm going to have to log some book time on how to actually setup a connection pool and implement it. Wish me luck! I have until March to get this sucker up and runnin'.
J.
P.S.
For the record, I HATE verification engineers!
 
Jim Baiter
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm curious about one thing - we have to communicate with
a bunch of devices with their native device drivers. I.E.
we have no choice about native. Do you think JNI is fastest
or what if I set up ORBs and used CORBA calls? Or are there
other better ways? There will be quite a few native calls
going on in this system. TIA
Originally posted by Ajith Kallambella:
Just a few thoughts.....
If anything, Connection pools certainly help object reuse and resource optimization. It is nothing more than an extension of object-pooling strategy where frequently accessed "expensive" objects are not discarded after use, but recycled.
Connection pooling is a good strategy if establishing a DB connection turnsout to be a time-consuming operation. Consider for example a multi-tier architecture where your app server( tier 2 ) is on a different box than the DB( tier 1 ). Here establishing a DB connection would involve some network traffic and a latency. If for every client request( from tier3 ) you have to connect to DB and process the request, discarding the connection after completing the request may not be a good idea. This scenario is an ideal candidate for using connection pooling.
On the otherhand, if you only had a limited ( and significantly ) number of clients and/or the application is based on a 2-tier architecture with the appserver and DB residing on the same machine, and/or if your network is fast so that latency is almost minimal, connection pooling might prove to be an overkill approach.

 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JNI should be faster then the ORB since the latter involves an additional level of indirection( going through the ORB ) to resolve object reference and "binding" to the correct object.
Am I right?
------------------
Ajith Kallambella M.
Sun Certified Programmer for the Java2 Platform.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!