Re: PostgreSQL XAResource & GlassFish 3.1.2.2

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Florent Guillaume <fg(at)nuxeo(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Bryan Varner <bvarner(at)polarislabs(dot)com>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: PostgreSQL XAResource & GlassFish 3.1.2.2
Date: 2013-02-12 18:47:54
Message-ID: CADK3HHK_FtmUTCp9i2k4HjPt0xW9GnO3aKF0P=62oY8LyvGWSg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Bryan,

Can you test Heikki's patch with your code. Florent any chance you can give
me java 5 patch or better yet a git pull

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On Tue, Feb 12, 2013 at 1:43 PM, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:

> We could patch it so that java 5+ didn't see this the driver already
> builds different versions
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
> On Tue, Feb 12, 2013 at 1:41 PM, Florent Guillaume <fg(at)nuxeo(dot)com> wrote:
>
>> On Tue, Feb 12, 2013 at 7:36 PM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)com> wrote:
>> > I see. I think there's yet another potential explanation: even if
>> glassfish
>> > is careful to invoke the end() only after start() has fully finished in
>> the
>> > other thread, the java memory model does not guarantee that the effects
>> of
>> > the end() in one thread are visible to the other thread doing the
>> start().
>> > The update of the PGXAConnection's state-variable might be sitting in
>> the
>> > CPU cache of the CPU running the first thread, not yet visible to the
>> second
>> > thread.
>>
>> That's the whole point of volatile since Java 5, it enforces a barrier
>> and "happens-before" semantics.
>>
>> > However, I'm not sure if glassfish could guarantee that the start()
>> > has really finished before end() is called, without using some operation
>> > that would also force the CPU cache to be flushed, making the effects
>> > visible.
>> >
>> > In any case, it seems like we should add "synchronized" to all the
>> public
>> > methods in PGXAConnection. The performance penalty should be minimal,
>> and it
>> > would fix any race conditions of that sort.
>>
>> For Java 5+ this is really overkill.
>>
>> Florent
>>
>> >
>> > Can you test the attached patch?
>> >
>> > - Heikki
>> >
>> >
>> > --
>> > Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
>> > To make changes to your subscription:
>> > http://www.postgresql.org/mailpref/pgsql-jdbc
>> >
>>
>>
>>
>> --
>> Florent Guillaume, Director of R&D, Nuxeo
>> Open Source, Java EE based, Enterprise Content Management (ECM)
>> http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>>
>
>

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Heikki Linnakangas 2013-02-12 18:48:48 Re: PostgreSQL XAResource & GlassFish 3.1.2.2
Previous Message Dave Cramer 2013-02-12 18:43:20 Re: PostgreSQL XAResource & GlassFish 3.1.2.2