 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Kenneth P. Turvey
Guest
|
 Posted: Sun Feb 08, 2004 5:55 am Post subject: Portable stored procedures |
 |
|
I was reading some Oracle documentation the other day on Java stored
procedures and found that I could write stored procedures that would
be database and platform independent. Is this really true? Does it
work out in practice?
I would like to use a Java based database on my Linux box to test some
of this out at home with the hope of using it at work at a later
date if it is a "good idea". I've just installed hypersonicDB on my
laptop and I'm suitably impressed. Is this a reasonable platform on
which to try this out? Are there any better 100% Java databases with
which to work? I'm not looking for production systems, just a
test bed.
TIA,
--
Kenneth P. Turvey <kt (AT) squeakydolphin (DOT) com>
Artificial Intelligence Algorithms Wiki
http://ai.squeakydolphin.com
|
|
| Back to top |
|
 |
Dennis
Guest
|
| Posted: Sun Feb 08, 2004 8:40 am Post subject: Re: Portable stored procedures |
|
|
JDatastore also uses java as the language for its stored procedures.
http://info.borland.com/techpubs/jdatastore/
from the above link, you can download the documentation for the database.
JDBC compliance is good, and the database itself is written in java.
It also have a nice features that lets you write binary streams to it, so in
addition to the database, you get yourself a virtual file system.
The main thing it has going against itself is that it is not a generational
database like Interbase and i think oracle.
Borland is about to release a new version, it is possible to download a
trial to check it out.
By the way - using java as the language for stored procedures is of course
extremely smart. They probably perform way better than other languages, and
you only have to develop the code once.
Performance is comparable to other (even non-java) databases. Java keeps on
getting faster and faster.
Dennis
"Kenneth P. Turvey" <kt (AT) squeakydolphin (DOT) com> wrote
| Quote: | I was reading some Oracle documentation the other day on Java stored
procedures and found that I could write stored procedures that would
be database and platform independent. Is this really true? Does it
work out in practice?
I would like to use a Java based database on my Linux box to test some
of this out at home with the hope of using it at work at a later
date if it is a "good idea". I've just installed hypersonicDB on my
laptop and I'm suitably impressed. Is this a reasonable platform on
which to try this out? Are there any better 100% Java databases with
which to work? I'm not looking for production systems, just a
test bed.
TIA,
--
Kenneth P. Turvey
Artificial Intelligence Algorithms Wiki
http://ai.squeakydolphin.com
|
|
|
| Back to top |
|
|
Robert Klemme
Guest
|
| Posted: Mon Feb 09, 2004 9:28 am Post subject: Re: Portable stored procedures |
|
|
"Dennis" <df (AT) tdc-broadband (DOT) dk> schrieb im Newsbeitrag
news:4025f667$0$1624$edfadb0f (AT) dread14 (DOT) news.tele.dk...
| Quote: | JDatastore also uses java as the language for its stored procedures.
http://info.borland.com/techpubs/jdatastore/
from the above link, you can download the documentation for the
database.
JDBC compliance is good, and the database itself is written in java.
It also have a nice features that lets you write binary streams to it,
so in
addition to the database, you get yourself a virtual file system.
|
Well, that's not really a surprising feature: nearly all db's you can get
today support BLOB's.
| Quote: | The main thing it has going against itself is that it is not a
generational
database like Interbase and i think oracle.
Borland is about to release a new version, it is possible to download a
trial to check it out.
By the way - using java as the language for stored procedures is of
course
extremely smart. They probably perform way better than other languages,
and
you only have to develop the code once.
|
I haven't used Java stored procedures with databases but your statement is
only true, if all databases involved had the same API's and conventions
regarding stored procedure parameters, return values and exceptions.
Apart from that, Java stored procedures are not necessarily faster than
stored procedures written in some proprietary language.
I personally would not believe promises that claim portable stored
procedures. From my experience stored procedures is one of the fields
where databases differ most.
| Quote: | Performance is comparable to other (even non-java) databases. Java keeps
on
getting faster and faster.
|
That may be true as the main performance factor of a database is the
smartness of the algorithms and disk speed. Nevertheless I would not
expect a db implemented using Java to be as performant as any other native
compiled db. There are some obstacles to that (object creation
overerhead, memory size limits for JVM's on certain platforms etc.).
Kind regards
robert
| Quote: |
Dennis
"Kenneth P. Turvey" <kt (AT) squeakydolphin (DOT) com> wrote in message
news:slrnc2bjpl.45h.kt (AT) premium (DOT) geo.yahoo.akadns.net...
I was reading some Oracle documentation the other day on Java stored
procedures and found that I could write stored procedures that would
be database and platform independent. Is this really true? Does it
work out in practice?
I would like to use a Java based database on my Linux box to test some
of this out at home with the hope of using it at work at a later
date if it is a "good idea". I've just installed hypersonicDB on my
laptop and I'm suitably impressed. Is this a reasonable platform on
which to try this out? Are there any better 100% Java databases with
which to work? I'm not looking for production systems, just a
test bed.
TIA,
--
Kenneth P. Turvey
Artificial Intelligence Algorithms Wiki
http://ai.squeakydolphin.com
|
|
|
| Back to top |
|
|
Dennis
Guest
|
| Posted: Mon Feb 09, 2004 10:23 am Post subject: Re: Portable stored procedures |
|
|
| Quote: | It also have a nice features that lets you write binary streams to it,
so in
addition to the database, you get yourself a virtual file system.
Well, that's not really a surprising feature: nearly all db's you can get
today support BLOB's.
|
JDatastore lets you store binary streams outside the table scema. You can
store them in a directory structure. A BLOB (which is of course supported by
allmost all databases today) is usually a binary field stored in a record in
a table.
| Quote: | By the way - using java as the language for stored procedures is of
course
extremely smart. They probably perform way better than other languages,
and
you only have to develop the code once.
I haven't used Java stored procedures with databases but your statement is
only true, if all databases involved had the same API's and conventions
regarding stored procedure parameters, return values and exceptions.
|
What i meant is that if you have for instance a function to parse or change
a string, that was needed in the client and in the server - in many cases,
you will have to write the function in the client in Java (or whatever
language you are using) and in the server in some sql-script language - or C
for speed. With JDatastore, you can put the same class on client and server,
therefore ensuring that the client executes the same functions as the server
for the same tasks.
| Quote: | Apart from that, Java stored procedures are not necessarily faster than
stored procedures written in some proprietary language.
|
Not neccesarily, i agree. That would be up to a test.
| Quote: | I personally would not believe promises that claim portable stored
procedures. From my experience stored procedures is one of the fields
where databases differ most.
|
I didn't mean portable *that* way. i meant that you have the opportunity to
re-use certian classes in the client, in the middle layer, and inside the
SQL server. If you store a string in a row, and the string needs to be
compliant to some syntax, the syntax check can be written in java as a
class, and this class can be used in the client for offline checking, and in
the server for online checking. This way, you ensure that it is exactly the
same code that checks on the client and on the server.
| Quote: | Performance is comparable to other (even non-java) databases. Java keeps
on
getting faster and faster.
That may be true as the main performance factor of a database is the
smartness of the algorithms and disk speed. Nevertheless I would not
expect a db implemented using Java to be as performant as any other native
compiled db. There are some obstacles to that (object creation
overerhead, memory size limits for JVM's on certain platforms etc.).
|
Actually, with java versions running on sdk 1.2 (1.4.1 and 1.4.2 i think)
from SUN, the creation of an object is comparable or faster than C and C++.
Reason being that the heap is guarenteed to be unfragmented, and thus,
addition of an object is simply a matter of adding to a pointer.
Object dallocation is very fast for shortlived objects. So fast that sun's
tests suggests that object pooling of small objects is outperformed by
creating and removing these objects.
Reason is that the garbage collector copies any surviving objects, then
wipes that part of the heap. So it takes the same amount of constant time to
GC 10000 objects, as it takes to GC 10 objects. What matter is the number of
objects that live longer than the shortest GC interval.
there is a discussion on this subject at
http://www-106.ibm.com/developerworks/library/j-jtp01274.html?ca=dnt-54
(not sure if you have to be a member to read it. if so - become member, it
is free, and they post good stuff from time to time)
a slideshow highligthing important changes to sun's JVM:
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/1522.pdf
You do mention one thing that is VERY important to those who are about to
consider database for a big project... platforms... Java is performing very
very fast on the windows/intel platform, but is not performing as well on
some other platforms (it will in due time, but i guess the newest JVM's on
these platforms are a little older, or not as optimized). You might end up
with running a 300% slower JVM on a 200% faster unix box, compared to a
windows/intel. Therefore - if you are deploying onto some heavy duty
equipment, check out that you have the newest JVM, and check out if it
performs well. I'm sure there is no problem on the most popular platforms
(ibm, linux, whatever).
Dennis
|
|
| Back to top |
|
|
Robert Klemme
Guest
|
| Posted: Mon Feb 09, 2004 12:05 pm Post subject: Re: Portable stored procedures |
|
|
"Dennis" <df (AT) tdc-broadband (DOT) dk> schrieb im Newsbeitrag
news:40276024$0$1599$edfadb0f (AT) dread14 (DOT) news.tele.dk...
| Quote: |
It also have a nice features that lets you write binary streams to
it,
so in
addition to the database, you get yourself a virtual file system.
Well, that's not really a surprising feature: nearly all db's you can
get
today support BLOB's.
JDatastore lets you store binary streams outside the table scema. You
can
store them in a directory structure. A BLOB (which is of course
supported by
allmost all databases today) is usually a binary field stored in a
record in
a table.
|
What do you gain by this? Other databases usually do not store BLOB's
physically at the same page as other fields of a record. So there
shouldn't be performance issue.
| Quote: | By the way - using java as the language for stored procedures is of
course
extremely smart. They probably perform way better than other
languages,
and
you only have to develop the code once.
I haven't used Java stored procedures with databases but your
statement is
only true, if all databases involved had the same API's and
conventions
regarding stored procedure parameters, return values and exceptions.
What i meant is that if you have for instance a function to parse or
change
a string, that was needed in the client and in the server - in many
cases,
you will have to write the function in the client in Java (or whatever
language you are using) and in the server in some sql-script language -
or C
for speed. With JDatastore, you can put the same class on client and
server,
therefore ensuring that the client executes the same functions as the
server
for the same tasks.
|
Ok, that's true.
| Quote: | Apart from that, Java stored procedures are not necessarily faster
than
stored procedures written in some proprietary language.
Not neccesarily, i agree. That would be up to a test.
I personally would not believe promises that claim portable stored
procedures. From my experience stored procedures is one of the fields
where databases differ most.
I didn't mean portable *that* way. i meant that you have the opportunity
to
re-use certian classes in the client, in the middle layer, and inside
the
SQL server.
|
So you meant "reuse" while writing "portability" - actually two very
different concepts.
| Quote: | Performance is comparable to other (even non-java) databases. Java
keeps
on
getting faster and faster.
That may be true as the main performance factor of a database is the
smartness of the algorithms and disk speed. Nevertheless I would not
expect a db implemented using Java to be as performant as any other
native
compiled db. There are some obstacles to that (object creation
overerhead, memory size limits for JVM's on certain platforms etc.).
Actually, with java versions running on sdk 1.2 (1.4.1 and 1.4.2 i
think)
from SUN, the creation of an object is comparable or faster than C and
C++.
Reason being that the heap is guarenteed to be unfragmented, and thus,
addition of an object is simply a matter of adding to a pointer.
|
There's some additional management overhead involved so it's not that
simple. I'm not going to dig deeper into this since then it would be
drifting too far off-topic...
| Quote: | Object dallocation is very fast for shortlived objects. So fast that
sun's
tests suggests that object pooling of small objects is outperformed by
creating and removing these objects.
Reason is that the garbage collector copies any surviving objects, then
wipes that part of the heap. So it takes the same amount of constant
time to
GC 10000 objects, as it takes to GC 10 objects. What matter is the
number of
objects that live longer than the shortest GC interval.
there is a discussion on this subject at
http://www-106.ibm.com/developerworks/library/j-jtp01274.html?ca=dnt-54
(not sure if you have to be a member to read it. if so - become member,
it
is free, and they post good stuff from time to time)
|
You don't need to. Thanks for that link. I'll have a look.
| Quote: | a slideshow highligthing important changes to sun's JVM:
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/1522.pdf
You do mention one thing that is VERY important to those who are about
to
consider database for a big project... platforms... Java is performing
very
very fast on the windows/intel platform, but is not performing as well
on
some other platforms (it will in due time, but i guess the newest JVM's
on
these platforms are a little older, or not as optimized). You might end
up
with running a 300% slower JVM on a 200% faster unix box, compared to a
windows/intel. Therefore - if you are deploying onto some heavy duty
equipment, check out that you have the newest JVM, and check out if it
performs well. I'm sure there is no problem on the most popular
platforms
(ibm, linux, whatever).
|
Even more so benchmark the VM's and profile applications.
Regards
robert
|
|
| Back to top |
|
|
sshaughnessy
Guest
|
| Posted: Tue Feb 10, 2004 6:33 am Post subject: Re: Portable stored procedures |
|
|
The JDataStore file system is a single file store. In addition to the
storage of tables, it allows random access file streams to be
organized in a directory. Of course you can also store these as blobs
in a table as well. The idea was to provide a portable,
transactional, encryptable file system of database tables and
arbitrary file streams. The support for file streams was added
because it was easy, not because a lot of customers asked for it.
The performance of stored procedures is probably more dependent on the
runtime, then the stored procedure language itself. However, the
execution of byte code compiled by hot spot is probably faster than
any sql based stored procedure language. There was a huge investment
in making hotspot and the jvm memory management which is not likely to
be matched by a proprietary stored procedure language. A managed code
language like java (no error prone pointers, memory management and
exception handling) provides a trustworthy, powerful, object oriented
language for writing stored procedures. Debugging and profiling java
stored procedures can also be performed with high quality general
purpose tools as well.
As for the performance of java vs native databases, my experience is
that it still boils down to the quality of your algorithms. For the
most part I've been able to make raw java code as fast as C++. Most
of the exceptions come from inefficient practices in sun's runtime
java class libraries.
There are an infinite number of ways to benchmark a database, so I
won't say JDataStore is faster than any particular database across the
board, but we have numerous real world cpu/memory intensive benchmarks
where JDataStore decisively out performs popular established high
performance native databases. That said it is easy to make slow java
code and as I mentioned before, sun has accomplished this many times
in their java runtime classes.
|
|
| Back to top |
|
|
Jeff Rhines
Guest
|
| Posted: Wed Feb 11, 2004 1:03 pm Post subject: Re: Portable stored procedures |
|
|
"Dennis" <df (AT) tdc-broadband (DOT) dk> wrote
| Quote: | You do mention one thing that is VERY important to those who are about to
consider database for a big project... platforms... Java is performing
very
very fast on the windows/intel platform, but is not performing as well on
some other platforms (it will in due time, but i guess the newest JVM's on
these platforms are a little older, or not as optimized). You might end up
with running a 300% slower JVM on a 200% faster unix box, compared to a
windows/intel. Therefore - if you are deploying onto some heavy duty
equipment, check out that you have the newest JVM, and check out if it
performs well. I'm sure there is no problem on the most popular platforms
(ibm, linux, whatever).
Dennis
|
Dennis,
Can you provide some references to the numbers you quote above? I've
noticed significant differences between running java apps on windows vs
solaris. I'd like to see what results (benchmark or otherwise)others get.
Jeff
|
|
| Back to top |
|
|
David Morse
Guest
|
| Posted: Fri Feb 27, 2004 9:09 pm Post subject: Re: Portable stored procedures |
|
|
Yes - try FirstSQL/J - Java SPs and much more functions and performance that
HSQL.
www.firstsql.com
"Kenneth P. Turvey" <kt (AT) squeakydolphin (DOT) com> wrote
| Quote: | I was reading some Oracle documentation the other day on Java stored
procedures and found that I could write stored procedures that would
be database and platform independent. Is this really true? Does it
work out in practice?
I would like to use a Java based database on my Linux box to test some
of this out at home with the hope of using it at work at a later
date if it is a "good idea". I've just installed hypersonicDB on my
laptop and I'm suitably impressed. Is this a reasonable platform on
which to try this out? Are there any better 100% Java databases with
which to work? I'm not looking for production systems, just a
test bed.
TIA,
--
Kenneth P. Turvey
Artificial Intelligence Algorithms Wiki
http://ai.squeakydolphin.com
|
|
|
| Back to top |
|
|
Malte Finsterwalder
Guest
|
| Posted: Mon Mar 01, 2004 4:32 pm Post subject: Re: Portable stored procedures |
|
|
On Sat, 7 Feb 2004 23:55:01 -0600, "Kenneth P. Turvey"
<kt (AT) squeakydolphin (DOT) com> wrote:
| Quote: | I was reading some Oracle documentation the other day on Java stored
procedures and found that I could write stored procedures that would
be database and platform independent. Is this really true? Does it
work out in practice?
|
Java Stored Procedures are Part 1 of SQLj.
(Part 0 is embeded SQL, Part 2 is Java Types to Sql Datatypes)
It's standardized, so Java SPs that apply SQLj should be portable
across DBs that support SQLj Part 1.
I have know practical experience with portability though.
I only tried it on DB2.
Greetings,
Malte
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
