Re: java stored procedures

Laszlo,

> I am very far from features like this.
> PL/JAVA now:
> -there is a separate process running java (kaffe). this process creates
> a sys v message queue, that holds requests. almost forgot, a shared
> memory segment too. I didn`t find better way to tell postgres the
> informations about the java process.

Does the mechanism you are planning support running any JVM? In my
opionion Kaffe isn't good enough to be widely useful. I think you
should be able to plugin whatever jvm is best on your platform, which
will likely be either the Sun or IBM JVMs.

Also, can you explain this a little bit more. How does the jvm process
get started? (I would hope that the postgresql server processes would
start it when needed, as opposed to requiring that it be started
separately.) How does the jvm access these shared memory structures?
Since there aren't any methods in the java API to do such things that I
am aware of.

> -the java request_handler function on the server side attaches to the
> shared memory, reads the key of the message queue., attaches to it,
> sends the data of the function, and a signal for the pl/java. after, it
> is waiting for a signal from the java thread.

I don't understand how you do this in java? I must not be understanding
something correctly here.

> -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?

> -And postgres is runing, while java is waiting for postgres to say
> something.

But in reality if the postgres process is executing a stored function it
needs to wait for the result of that function call before continuing
doesn't it?

>
> Threading on the java process side is not done yet, ok, it is not that
> hard, I will write it, if it will be realy neccessary.

Agreed, this is important.

>
> The problems, for now:
> I had a very simple system, that passed a very limited scale of argument
> types, with a very limited quantity of parameters (int, varchar, bool).
> Postgres has limits for the argument count too, but not for types. It
> had too much limits, so I am working (or to tell the truth now only
> thinking) on a new type handling that fits the felxibility of
> Postgresql`s type flexibility. For this I will have to learn a lot about
> Postgres`s type system. This will be my program this weekend. :)

Shouldn't this code use all or most of the logic found in the FE/BE
protocol? Why invent and code another mechanism to transfer data when
one already exists. (I will admit that the current FE/BE mechanism
isn't the ideal choice, but it seems easier to reuse what exists for now
and improve on it later).

>
> thanks,
> Laszlo Hornyak
>

You didn't mention how you plan to deal with the transaction symantics.
So what happens when the pl/java function calls through jdbc back to
the server to insert some data? That should happen in the same
transaction as the caller correct?

thanks,
--Barry