From: taniguchi.yasu at jp.fujitsu.com (Taniguchi, Yasunori)
Date: Fri, 20 Dec 2013 04:51:28 +0000
Subject: [Pljava-dev] doubtful PL/Java's activity
In-Reply-To: <52AAA743.40309@tada.se>
References: <2AB2177C63D24C43AC3BDE9A3A8F71FC1C86280C@G01JPEXMBYT02>
 <52A970BB.8030904@tada.se>
 <2AB2177C63D24C43AC3BDE9A3A8F71FC1C86B431@G01JPEXMBYT02>
 <52AAA743.40309@tada.se>
Message-ID: <2AB2177C63D24C43AC3BDE9A3A8F71FC1C86DA16@G01JPEXMBYT02>

Thank you, Mr. Thomas,

Sorry for my late response.

> The backend is single threaded (each connection runs in it's own process and it's own JVM) so there will never be two functions executing simultanously.

Yes, I understand.
But, multi thread applications (unless using concurrent JDBC  call) can run in JavaVM even if postgres backend is single threaded, I think.

After received this mail, I discussed with colleague and recognized :

- PL/Java runs without any problems even if PL/Java's and JavaVM's are compiled as multi thread library.
  Single thread compiled application uses standard library which contains thread-unsafe functions.
  These thread-unsafe functions uses common global variable between them. Therefore they are thread-unsafe.
  On the other hand, multi thread complied application uses standard library consists of thread-safe functions.
  Thread-safe functions uses separated global variables.
  As above, there is no problem unless any global variable (eg. errno) is passed across between single thread compiled application and multi thread one.

- PL/Java runs without any problems even if multi thread Java applications not using concurrent JDBC call runs.

In addition,
Java multi thread application can run thread-unsafe function in single thread library through JNI.
But, this case is abuse.


Any comments are appreciated.


Regards, taniguchi

-----Original Message-----
From: Thomas Hallgren [mailto:ironjug at gmail.com] On Behalf Of Thomas Hallgren
Sent: Friday, December 13, 2013 3:21 PM
To: Taniguchi, Yasunori 
Subject: Re: [Pljava-dev] doubtful PL/Java's activity

On 2013-12-13 02:57, Taniguchi, Yasunori wrote:
> Hi,
>
> Thank you, everyone.
> Excuse me my poor explanation.
> So, I made a figure.
> Look attachment.
> Red arrow in this fig. is unlikely ?
The backend is single threaded (each connection runs in it's own process and it's own JVM) so there will never be two functions executing simultanously.

>
>> You may, of course, have multiple Java threads in the JVM that resides in the PostgreSQL session.  But any interaction with the session is serialized, so this isn?t a problem at all.
> I worry about interaction between PostgreSQL and JVM library functions rather than interaction with the session.
Again, PostgreSQL is single threaded. It cannot interact in more than 
one thread.

>
>> PL/Java goes to some length in protecting the single threaded PostgreSQL kernel. All accesses to it must be made from the caller thread. Multiple threads > can be used for background tasks but such threads will be completely blocked from accessing the PostgreSQL functions.
>>
>> It works like this:
>> A call is made from PostgreSQL. This call grabs a mutex.
>> During PL/Java execution, only the thread that owns the mutex can call PostgreSQL.
>> When the call eventually returns, the mutex is released.
> If I'm correct, PL/Java is also a single thread library ?
> If so, it would not be a problem.
No, PL/Java is not a single thread library. There is however, never more 
than one thread that calls on it and never more than one thread that can 
call out from it.

>
>> Java maintenance (garbage collection for instance) will still run in separate threads. If someone should write a finalizer that actually tries to do database access (god forbid), then that finalizer would throw an exception.
> Uh.. It may become a restriction of usage.
> Probably, some restrictions else would exist, doesn't it?

Yes, it is a very deliberate restriction of usage. Don't start new 
threads that uses the JDBC driver. Don't use the JDBC driver from a 
finalizer. Both those cases would violate the single threaded nature of 
the backend.

- thomas