Re: implemention of calls to stored procs. - Mailing list pgsql-general

From Nic Ferrier
Subject Re: implemention of calls to stored procs.
Date
Msg-id 87sn8xuvmz.fsf@tf1.tapsellferrier.co.uk
Whole thread Raw
In response to Re: implemention of calls to stored procs.  (Holger Krug <hkrug@rationalizer.com>)
Responses Re: implemention of calls to stored procs.  (Holger Krug <hkrug@rationalizer.com>)
List pgsql-general
Holger Krug <hkrug@rationalizer.com> writes:

> On Wed, Jan 23, 2002 at 11:32:04AM +0000, Nic Ferrier wrote:
> > As for your 1st objective... I don't think that would be easy, even
> > with what I'm proposing there would have to be some sort of RMI or
> > CORBA link to the remote app.
> As far as I know, GCJ provides RMI libs, although not 100% tested.  It
> should be relatively easy because you must not handle transactions.

We haven't tested RMI, I don't know anyone who has tried to use it
with GCJ.

No problem though because I think CORBA ORBS have been tested.


> Concerning your implementation. Did I understand you right, that
> you've implemented your own Connection class, in an instance of which
> you encapsulate the current backend transaction ? If yes, so OK, it's
> probably simpler than getting RMI to work, and really nice.

Yes, I've implemented a native Connection class using the SPI stuff.

I don't think that solves any problem with your second objective
though, the problem is the remoteness of the java code. My java stored
procs will be just like C ones, running on the database server
machine (and tied to the pg process). Presumably what you're wanting
to do is notify some Java code outside of the pg process, for that
you'd need some remote signalling mechanism.


Nic

pgsql-general by date:

Previous
From: Holger Krug
Date:
Subject: Re: implemention of calls to stored procs.
Next
From: Nicolas Bouthors
Date:
Subject: zrn