Re: Portable stored procedures
From: Dennis (df_at_tdc-broadband.dk)
Date: 02/09/04
- Next message: Robert Klemme: "Re: Portable stored procedures"
- Previous message: John Casey: "XApool +multiple replicated nodes"
- In reply to: Robert Klemme: "Re: Portable stored procedures"
- Next in thread: Robert Klemme: "Re: Portable stored procedures"
- Reply: Robert Klemme: "Re: Portable stored procedures"
- Reply: Jeff Rhines: "Re: Portable stored procedures"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 9 Feb 2004 11:23:34 +0100
> > 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.
> > 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.
> 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. 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.
> > 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
- Next message: Robert Klemme: "Re: Portable stored procedures"
- Previous message: John Casey: "XApool +multiple replicated nodes"
- In reply to: Robert Klemme: "Re: Portable stored procedures"
- Next in thread: Robert Klemme: "Re: Portable stored procedures"
- Reply: Robert Klemme: "Re: Portable stored procedures"
- Reply: Jeff Rhines: "Re: Portable stored procedures"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
