Re: java stored procedures - Mailing list pgsql-general

From Barry Lind
Subject Re: java stored procedures
Date
Msg-id 3C0CFD82.1030600@xythos.com
Whole thread Raw
In response to java stored procedures  (Laszlo Hornyak <hornyakl@freemail.hu>)
Responses Re: java stored procedures
List pgsql-general
Laszlo,

I think it would help a lot if you could take a little time to write
down what your planned architecture for a pljava would be.  It then
becomes much easier for myself and probably others reading these lists
to make suggestions on ways to improve what you are planning (or
possible problems with your strategy).  Without knowing what exactly you
are thinking of doing it is difficult to comment.

But let me try throwing out a few thoughts about how I think this should
be done.

First question is how will the jvm be run?  Since postgres is a
multiprocess implementation (i.e. each connection has a separate process
on the server) and since java is a multithreaded implementation (i.e.
one process supporting multiple threads), what should the pljava
implementation look like?  I think there should be a single jvm process
for the entire db server that each postgresql process connects to
through sockets/rmi.  It will be too expensive to create a new jvm
process for each postgresql connection (expensive in both terms of
memory and cpu, since the startup time for the jvm is significant and it
requires a lot of memory).

Having one jvm that all the postgres backend processes communicate with
makes the whole feature much more complicated, but is necessary in my
opinion.

Then the question becomes how does the jvm process interact with the
database since they are two different processes.  You will need some
sort of interprocess communication between the two to execute sql
statements.  This could be accomplished by using the existing jdbc
driver.  But the bigest problem here is getting the transaction
semantics right.  How does a sql statement being run by a java stored
procedure get access to the same connection/transaction as the original
client?  What you don't want happening is that sql issued in a stored
java procedure executes in a different transaction as the caller, what
would rollback of the stored function call mean in that case?

I am very interested in hearing what your plans are for pl/java.  I
think this is a very difficult project, but one that would be very
useful and welcome.

thanks,
--Barry




Laszlo Hornyak wrote:

> Hi!
>
> I am such a lame in the licensing area. As much as I know, BSD license
> is more free than GPL. I think it is too early to think about licensing,
> but it`s ok, you won :), when it will be ready(or it will seem to get
> closer to a working thing, currently it looks more like a interresting
> test), I will ask you if you want to distribute it with Postgres, and if
> you say yes, the license will be the same as Postgresql`s license.
> Anyway is this neccessary when it is the part of the distribution?
> Is this ok for you?
>
> thanks,
> Laszlo Hornyak
>
> ps: still waiting for your ideas, suggestions, etc :) I am not memeber
> of the mailing list, please write me dirrectly!
>
> Barry Lind wrote:
>
>> Laszlo,
>>
>> In my mind it would be more useful if this code was under the same
>> license as the rest of postgresql.  That way it could become part of
>> the product as opposed to always being a separate component.  (Just
>> like plpgsql, pltcl and the other procedural languages).
>>
>> thanks,
>> --Barry
>>
>>
>
>



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Problem (bug?) with like
Next
From: Doug McNaught
Date:
Subject: Re: java stored procedures