Oliver Jowett wrote:
Thomas Hallgren wrote:
PL/Java runs a JVM. Since a JVM is multi threaded, PL/Java goes to
fairly extreme measures to ensure that only one thread at a time can
access the backend. So far, this have worked well but there is one small
problem. [...]
I assume this means you have a single lock serializing requests to the
backend?
Yes, of course. I also make sure that the main thread cannot return
until another thread that is servicing a backend request has completed.
There's absolutely no way two threads can execute backend code
simultaniously.
If you can't solve the depth checking problem (Tom doesn't seem to like
the idea of multiple threads calling into the backend..), what about
turning the original thread (i.e. the "main" backend thread) into a
"backend interface thread" that does nothing but feed callbacks into the
backend on request? Then run all the user code in a separate thread that
passes backend requests to the interface thread rather than directly
executing them. If it starts extra threads which makes DB requests, the
mechanism stays the same..
I though about that. The drawback is that each and every call must spawn
a new thread, no matter how trivial that call might be. If you do a
select from a table with 10,000 records and execute a function for each
record, you get 20,000 context switches. Avoiding that kind of overhead
is one of the motivating factors for keeping the VM in-process.
I don't rule out such a solution but I'd like to have a discussion with
Tom and iron out what the problems are when one thread at a time is
allowed to execute. Perhaps I can solve them.
Regards,
Thomas Hallgren
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
