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: