Re: [GENERAL] java stored procedures

Barry Lind wrote:

>
> I also stopped cc'ing the general list, since this is getting too
> detailed for most of the members on that list.

Ok.

> Now to your mail:
>
> This seems like a reasonable approach and should work across different
> JVMs.  It would probably be a good experiment to try this with the Sun
> or IBM jvm at some point to verify.  What I was afraid of was that you
> were hacking the Kaffe code to perform the integration which would
> limit this solution to only using Kaffe.

I am sure they wont work the same way. I think I have a sun jdk 1.3.0-2,
so I will try to port it soon. The IBM implementation must wait I think
until january.

>
> Just a suggestion:  PL/J might be a good name, since as you probably
> know it can't be called pl/java because of the trademark restrictions
> on the word 'java'.

Ok, you won, I do not read the licenses. From now it`s name is pl/j.
Isn`t 'j' too short for the name of the process that runns java? :)

>
> I am a little concerned about the stability and complexity of having
> this '-pizza' program be responsible for handling the calls on the
> java side.  My concern is that this will need to be a multithreaded
> program since multiple backends will concurrently be needing to
> interact with multiple java threads through this one program.  It
> might be simpler if each postgres process directly communicated to a
> java thread via a tcpip socket.  Then the "-pizza" program would only
> need to be responsible for starting up the jvm and creating java
> threads and sockets for a postgres process (it would perform a similar
> role to postmaster for postgres client connections).

With good design we can solve stability problems. As much as I know, if
postmaster dies, the postgres server becomes unavailable, this looks the
same problem. I do not know if we realy need sockets. Anyway, if 'j'
dies, we can create a new one, and restart calculations. Some watchdog
functionality...
Doing thing with sockets need a lot of rework. It is the best time for
this, while there is not too much thing done.

>>>
>>>> -when java thread receives the signal, it reads the message(s) from
>>>> the queue, and starts some actions. When done it tells postgres
>>>> with a signal that it is ready, and it can come for its results.
>>>> This will be rewritten see below problems.
>>>
>>> Are signals the best way to accomplish this?
>>
>> I don`t know if it is the best, it is the only way I know :)
>> Do you know any other ways?
>>
> I don't know, but hopefully someone on the hackers list will chip in
> here with a comment.

After a first developement cycle (if my brain doesn`t burn down), the
signals can be replaced to a plugable communication interface I think.
So maybe we can use CORBA, or sockets, or something else. This will take
a lot of time.

> OK, so the same backend process that called the function gets messaged
> to process the sql.  This should work.  However it means you will need
> a special version of the jdbc driver that uses this shm+signals
> communication mechanism instead of what the current jdbc driver does.
> This is something I would be happy to help you with.


This is kind of you. :)
For this, I will have to finish the protocol of communication. I have to
learn Postgres enough, so I am not sure this will be done this weekend.
I have ideas, only time is needed to implement them or to recognize the
failures.

Thanks,
Laszlo Hornyak