On Mon, Feb 23, 2004 at 05:14:09PM +0100, Peter Eisentraut wrote:
> Thomas Hallgren wrote:
> > 1. Select Pl/Java_JNI.
> > 2. Select Pl/Java_remote
> > 3. Choose both and agree on the SQL + Java semantics
> > 4. Make the postmaster spawn threads rather than processes
> > (controversial? Nah :-) )
>
Tom Lane wrote:
> "Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> > ** 4. Make the postmaster spawn threads rather than processes **
> > I know this is very controversial and perhaps I should not bring it up at
> > all. But then again, why not? Most readers are open-minded right?
>
> It's been con
Hi all!
Sorry for my latencies.
An IRC chat is ok for me, anytime.
On Sun, Feb 22, 2004 at 08:08:00PM +0100, Thomas Hallgren wrote:
> I'm in Sweden. Some time tuesday evening (european time) perhaps?
>
> Why is your work not made public somewhere? The project on sourceforge is
> inactive it seem
> On the re-use front it would be VERY nice if you could
> somehow have a single patch for PostgreSQL's C code that called a set of
> Java interfaces. Then each of your implementations could implement that
set
> of Java interfaces (one using JNI, the other using RMI). This would allow
> the user
Hello all,
>
> 3. Probe deeper and see if there's more that we can share (C-code
> essentially).
> I have my doubts about sharing C-code since we do things fundamentally
> different. I know you have a generic call mechanism that we could use to
> establish a common ground, but I think it would bad
Thomas Hallgren
- Original Message -
From: "Dave Cramer" <[EMAIL PROTECTED]>
To: "HORNYAK Laszlo" <[EMAIL PROTECTED]>
Cc: "Thomas Hallgren" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, February 23, 2004 13:41
Subject: Re: [HACKERS]
> Option 5 (or 0) would be to use GCJ. This is likely to be the fastest
> and most lightweight solution, but perhaps not the most featureful.
>
GCJ is definitely an alternative for the reasons you mention. I didn't
mention it (nor any other JVM) because I see it as one of several "JVM's"
that Pl/J
Thomas Hallgren wrote:
> 1. Select Pl/Java_JNI.
> 2. Select Pl/Java_remote
> 3. Choose both and agree on the SQL + Java semantics
> 4. Make the postmaster spawn threads rather than processes
> (controversial? Nah :-) )
Option 5 (or 0) would be to use GCJ. This is likely to be the fastest
and mos
tues evening euro time is fine with me. I am at GMT-5 so it will be
afternoon for me. What time ?
We should attempt an agenda?
Dave
On Sun, 2004-02-22 at 15:33, HORNYAK Laszlo wrote:
> Hi all!
>
> Sorry for my latencies.
> An IRC chat is ok for me, anytime.
>
> On Sun, Feb 22, 2004 at 08:08:00P
One perfectly good reason for this scenario is portability between
postgres and any database implementing the standard (e.g. Oracle).
cheers
andrew
Dave Cramer wrote:
Not to minimize your work, as I think it is great, but this particular
use-case I consider to be overkill for pl/java. It is pr
I'm in Sweden. Some time tuesday evening (european time) perhaps?
Why is your work not made public somewhere? The project on sourceforge is
inactive it seems. Do you have a CVS setup privately?
> Not to minimize your work, as I think it is great, but this particular
> use-case I consider to be ov
Not to minimize your work, as I think it is great, but this particular
use-case I consider to be overkill for pl/java. It is probably easier to
use pl/pgsql if all you want to do is calculations.
We had suggested an online chat to discuss this, when would you be
available for that? What timezone a
> 1) Using JNI, you probably still want to communicate with another
> running java process.
B.T.W. I don't really agree on "probably". There are numerous cases when you
will be happy just communicating with the database, communicate with another
remote resource (message queue typically), or not co
Hi Dave,
Comments on your comments inline...
> What I would like to see is an abstraction of the interface that
> communicates with the JVM so that we can use either, as you have pointed
> out the JNI mechanism has advantages, as does the remote mechanism.
>
Yes, we must agree 100% on the "interf
Thomas,
What I would like to see is an abstraction of the interface that
communicates with the JVM so that we can use either, as you have pointed
out the JNI mechanism has advantages, as does the remote mechanism.
I recently did an analysis of the two methods and there are a couple of
other poi
Thomas Hallgren wrote:
That's an interesting thougth. The postmaster just forks. It never exec's
right? Is this true for win32 as well? I've never tried it but it might be
worth pursuing. Sun's new Java 1.5 jvm does this albeit a bit differently.
An initializer process starts up and persists its st
Thomas Hallgren wrote:
Other than that fear, though, the JNI approach seems to have pretty
considerable advantages. You listed startup time as the main
disadvantage, but perhaps that could be worked around. Suppose the
postmaster started a JVM --- would that state inherit correctly into
subseq
> It's been considered and rejected before, and pljava isn't going to tilt
> the scales.
>
Didn't think it would. Thought it worth mentioning anyway, partly to get
your reaction.
> In fact, the main thing that bothers me about your
> description of JNI is "Java uses multithreading wether you like
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> ** 4. Make the postmaster spawn threads rather than processes **
> I know this is very controversial and perhaps I should not bring it up at
> all. But then again, why not? Most readers are open-minded right?
It's been considered and rejected before,
Two Pl/Java implementations exists today. Due to the architecture of
PostgreSQL, compromises have been made in both of them to deal with the fact
that each connection lives in its own process. One, I'll call it
"Pl/Java_JNI" will spawn a JVM on demand for each connection and the other,
"Pl/Java_rem
20 matches
Mail list logo
