On Tue, Feb 12, 2013 at 7:36 PM, Heikki Linnakangas
<hlinnakangas@vmware.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@postgresql.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