[Pljava-dev] doubtful PL/Java's activity

If I understand you correctly, you?re talking about the recursive invocation case:

SQL -> PL/Java -> SQL - PL/Java

Yes, you are correct. If you have multiple threads running in your JVM, then you can get into serious trouble if you don?t know what you?re doing.

However:

why do you have multiple threads?
if you have multiple threads, then why aren?t you designing your systems to accommodate this?

Bottom line is that this should be completely under your control. In any event, it?s caveat emptor. With great power comes great responsibility. If you don?t want multithreaded problems, then don?t spawn multiple threads. You can install a security manager that prevents this, you know ;)

And if you have multiple threads in your stored procedure calls, then you?re going to have to deal with that. Not the responsibility of the PL/Java implementation to take care of the messes you, yourself, create.

On Dec 12, 2013, at 5:57 PM, Taniguchi, Yasunori <taniguchi.yasu at jp.fujitsu.com> wrote:

> Hi,
>
> Thank you, everyone.
> Excuse me my poor explanation.
> So, I made a figure.
> Look attachment.
> Red arrow in this fig. is unlikely ?
>
>
>> 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.
>
>
>> 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.
>
>
>> 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?
>
>
> Regards.
>
> -----Original Message-----
> From: pljava-dev-bounces at lists.pgfoundry.org [mailto:pljava-dev-bounces at lists.pgfoundry.org] On Behalf Of Thomas Hallgren
> Sent: Thursday, December 12, 2013 5:16 PM
> To: pljava-dev at lists.pgfoundry.org
> Subject: Re: [Pljava-dev] doubtful PL/Java's activity
>
> 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.
>
> 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.
>
> - thomas
>
> On 2013-12-09 12:16, Taniguchi, Yasunori wrote:
>> Hi,
>>
>> I'm investigating PL/Java and find out a doubtful fact.
>>
>> Postgres is compiled as a single thread application and linked with
>> JavaVM(.so/.dll) which is a multi thread library.
>> Sp, I think PL/Java's activity may not be assured.
>>
>> Thread-unsafe functions and global variables used in single thread
>> standard libraries may be inconsistent with multi thread libraries.
>>
>> Can anybody respond me ?
>>
>>
>> Regards.
>> -----
>> Y.Taniguchi
>>
>>
>> _______________________________________________
>> Pljava-dev mailing list
>> Pljava-dev at lists.pgfoundry.org
>> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
> <thread model evaluation.xls>_______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20131212/f8d79418/attachment.html>