Le mer. 8 mars 2023 à 16:23, Christopher Schultz <
ch...@christopherschultz.net> a écrit :
> Romain,
>
> On 3/8/23 04:10, Romain Manni-Bucau wrote:
> > Seems doing it only there will get back to the issue the synchronization
> > was introduced (there are other synchronized(session) for "local"
> i
Romain,
On 3/8/23 04:10, Romain Manni-Bucau wrote:
Seems doing it only there will get back to the issue the synchronization
was introduced (there are other synchronized(session) for "local" instance).
Don't forget that there are multiple reasons to synchronize on a
session, and they solve dif
Hi Chris,
Seems doing it only there will get back to the issue the synchronization
was introduced (there are other synchronized(session) for "local" instance).
However you hit a real point, the instance does not have to be stable, only
its equals/hashCode could be considered stable so guess the id
> On Mar 8, 2023, at 07:29, Christopher Schultz
> wrote:
>
> All,
>
> Please see https://bz.apache.org/bugzilla/show_bug.cgi?id=66513 for reference.
>
> It appears that the synchronization used by the PersistentManager can cause
> problems when used with the PersistentValve and DataSource/J
All,
Please see https://bz.apache.org/bugzilla/show_bug.cgi?id=66513 for
reference.
It appears that the synchronization used by the PersistentManager can
cause problems when used with the PersistentValve and DataSource/JDBCStore.
The problem is that PersistentManager assumes that the Sessio
