Looks like this is related to HHH-8679 and HHH-8939:
IIRC, the code in AbstractLoadPlanBasedLoader was copied from Loader.
Here's the commit that removed the comment you mention from Loader#
wrapResultSetIfEnabled and added a synchronized block to
retreiveColumnNameToIndexCache (HHH-8679):
https:
I did not add those comments; they were just in some code I copied over
into that class.
On Tue, Dec 15, 2015, 4:02 AM Sanne Grinovero wrote:
> On 15 December 2015 at 01:46, Steve Ebersole wrote:
> > It's very possible that code comments may no longer be pertinent.
>
> Right, that's what I'm tr
On 15 December 2015 at 01:46, Steve Ebersole wrote:
> It's very possible that code comments may no longer be pertinent.
Right, that's what I'm trying to figure out. Do you remember which
possible deadlock it might have referred to?
>
> On Mon, Dec 14, 2015 at 10:26 AM Sanne Grinovero
> wrote:
>
Hi,
Sorry for the confusion, I mistakenly replied on a different thread.
Vlad
On Tue, Dec 15, 2015 at 3:48 AM, Steve Ebersole wrote:
> I'm confused. Sanne was talking about a completely different piece of
> code from optimizers. Maybe you are mixing this and the other current
> hibernate-dev
I'm confused. Sanne was talking about a completely different piece of code
from optimizers. Maybe you are mixing this and the other current
hibernate-dev discussion?
On Mon, Dec 14, 2015 at 11:10 AM Vlad Mihalcea
wrote:
> Hi,
>
> We really need to test it thoroughly because the current pooled
It's very possible that code comments may no longer be pertinent.
On Mon, Dec 14, 2015 at 10:26 AM Sanne Grinovero
wrote:
> Hi all,
> while reviewing an improvement by Stale about reducing
> synchronization, I'm having the impression that the synchronization
> could be completely removed.
>
> Bu
Sanne, you just described the general approach of "short naming" for config
options overall :)
On Mon, Dec 14, 2015 at 6:28 PM Sanne Grinovero wrote:
> On 14 December 2015 at 17:10, Vlad Mihalcea
> wrote:
> > Hi,
> >
> > We really need to test it thoroughly because the current pooled optimize
On 14 December 2015 at 17:10, Vlad Mihalcea wrote:
> Hi,
>
> We really need to test it thoroughly because the current pooled optimizer
> are reasonably fast especially when used with a database sequence.
> The table generators are slow because of the row-level locking, so I won't
> include those i
Hi,
We really need to test it thoroughly because the current pooled optimizer
are reasonably fast especially when used with a database sequence.
The table generators are slow because of the row-level locking, so I won't
include those in this discussion.
What strikes me is the synchronized block w
Hi all,
while reviewing an improvement by Stale about reducing
synchronization, I'm having the impression that the synchronization
could be completely removed.
But there's a comment warning me against that, so for sake of safety
I'm merging the improvement without risking going too far:
// synch
10 matches
Mail list logo
