RE: Preferred method to access databases from Servlets

Ok, I don't want to continue with this discussion as it seems to be
something of an issue of how we choose to see things, but the AS/400 will
run CRTJVAPGM under the covers the first time a class file is run, create
the binary, and use that for future runs (if you specify the prompts that
way on the java command).

When you move the class file to any other system in the world, it continues
to work and that platform can determine how it chooses to handle that
execution.  Or you can use other tools to build executables for that
particular platform (it just isn't automated on other platforms).

Regards,

Richard D. Dettinger
AS/400 Java Data Access Team

"TRUE! nervous, very, very dreadfully nervous I had been and am; but why
WILL you say that I am mad?
The disease had sharpened my senses, not destroyed, not dulled them. "

- Edgar Allan Poe
"The Tell-Tale Heart"




Eric Merritt <cyberlync@yahoo.com>@midrange.com on 09/20/2000 08:36:14 AM

Please respond to JAVA400-L@midrange.com

Sent by:  owner-java400-l@midrange.com


To:   JAVA400-L@midrange.com
cc:
Subject:  RE: Preferred method to access databases from Servlets



Richard,

 How can you say that java is not interpreted? Ok I
will grant you that the CRTJVAPGM does produce system
binaries on the AS/400 but that command does not exist
on any other platform that I am aware of. As for the
JIT yes it does increase speed greatly, but it does
its compile at runtime therefore incurring that
overhead as it goes, this is not an indication of a
non interpreted language its just a different way to
interpret it.

 Java is still interpreted or close to it, and will be
until some one comes up with a good  cross - platform
compiler that will turn it into native code. Even this
option is probably not a good thing as we will loss
the ability to pick up a class file and run it
anywhere.



--- cujo@us.ibm.com wrote:
>
> Concerning double interpretation:
>
> 1) Java is not an interpreted language (or at least
> it doesn't have to be).
> Between JIT (which you can expect to skyrocket in
> performance in JDK 1.3 if
> everything I have seen it true) and the CRTJVAPGM
> command/support, you
> should not be interpreting Java code.  It runs as
> system binaries.
>
> 2) What you try to accomplish through
> caching/pooling is the reuse of Java
> objects to minimize any interpretation at that level
> as well.  A connection
> pool eliminates connection creation, a well built
> statement pool can remove
> an SQL statement interpretation (for most types of
> applications).
>
> My numbers are now rounded and coming from memory,
> but for the COMMON
> presentation I mentioned in my references note
> yesterday, I took the
> performance of doing a couple hundred SQL statements
> (inserts and queries)
> from 43 seconds with no pooling to about 24 seconds
> with connection pooling
> to 1.5 seconds with Statement pooling.  Consult the
> presentation info for
> more details.  The complete code to run the tests
> for yourself is in the
> .zip file if you choose to.  The example is, of
> course, contrived to be
> specific to what I want to show, but the performance
> gains you can get from
> JDBC object pooling are very much for real.  And
> most importantly, it is
> easy to do and doesn't hinder a good solid object
> oriented design.
>
> That is about all I have to say on the subject.  I
> stated before that I
> don't think we will ever beat native IO performance.
>  We can just get much
> closer than most people think and the code is easier
> to maintain and runs
> on any platform without modfication.
>
> Regards,
>
> Richard D. Dettinger
> AS/400 Java Data Access Team
>
> "TRUE! nervous, very, very dreadfully nervous I had
> been and am; but why
> WILL you say that I am mad?
> The disease had sharpened my senses, not destroyed,
> not dulled them. "
>
> - Edgar Allan Poe
> "The Tell-Tale Heart"
>
>
>
>
> Eric Merritt <cyberlync@yahoo.com>@midrange.com on
> 09/19/2000 11:13:03 AM
>
> Please respond to JAVA400-L@midrange.com
>
> Sent by:  owner-java400-l@midrange.com
>
>
> To:   JAVA400-L@midrange.com
> cc:
> Subject:  RE: Preferred method to access databases
> from Servlets
>
>
>
> Richard,
>
>   I agree with SQL/JDBC is the future infortunatly.
> But it is still slow, and will be for the forseable
> future. Basically what you are doing when do io
> through  an SQL/JDBC a interface is you are taking
> java , which is already interpreted, creating a
> statment and running that statement trough the
> driver,
> with th driver interpreting and executing the
> statement, I cannot  see how this double
> interpretation will ever be as fast as any type of
> record level access. No don't get me wrong if the
> speeds ever gets even close we will probably move
> over
> to the SQL/JDBC area just becuase the support and
> documentation is better if nothing else.
>
> I will check out the caching though, if it gives the
> performance increase you seem to think it will, then
> it may be worth while to look into it.
>
>
> Thanks
> Eric
>
>
> =====
> Eric Merritt
> Information Systems Consultant
> McCormack & Associates, Inc.
> Rock Hill, South Carolina
> (V) 803-327-3358 X 225
> eric@mccinc.com
> http://www.mccinc.com/
>
> __________________________________________________
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo!
> Messenger.
> http://im.yahoo.com/
> +---
> | This is the JAVA/400 Mailing List!
> | To submit a new message, send your mail to
> JAVA400-L@midrange.com.
> | To subscribe to this list send email to
> JAVA400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> JAVA400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner:
> joe@zappie.net
> +---
>
>
>
> +---
> | This is the JAVA/400 Mailing List!
> | To submit a new message, send your mail to
> JAVA400-L@midrange.com.
> | To subscribe to this list send email to
> JAVA400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> JAVA400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner:
> joe@zappie.net
> +---


=====
Eric Merritt
Information Systems Consultant
McCormack & Associates, Inc.
Rock Hill, South Carolina
(V) 803-327-3358 X 225
eric@mccinc.com
http://www.mccinc.com/

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---



+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---