[hibernate-dev] Optimize connection acquisition for RESOURCE_LOCAL transactions

[Vlad Mihalcea]

Hi,

I created the following issue so that we can allow our users to really use
delayed connection acquisitions for RESOURCE_LOCAL transactions:

https://hibernate.atlassian.net/browse/HHH-11542

This issue will not change the default behavior, so it's a safe change. The
user will have to explicitly set this new behavior that I'm proposing here.

Vlad
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] JDK 9 EA Build 159 and JDK 8u152 is available on java.net

[Rory O'Donnell]

Hi Sanne,

*JDK 8u152 **Early Access b01  *is 
available on java.net

*JDK 9 Early Access* b159   is 
available on java.net, summary of  changes are listed here 
.

There have been a number of fixes to bugs reported by Open Source 
projects since the last availability email  :

  * b159 - JDK-8175261 : Per-protocol cache setting not working for JAR
URLConnection
  * b158 - JDK-8173028 : Incorrect processing of supplementary-plane
characters in text fields
  * b158 - JDK-8172967 : [macosx] Exception while working with layout
for text containing unmappable character
  * b158 - JDK-8173804 : javadoc throws UnsupportedOperationException:
should not happen
  * b157 - JDK-8174073 : NPE caused by @link reference to class
  * b156 - JDK-8172726 : ForkJoin common pool retains a reference to the
thread context class loader

The following changeset is included in jdk-9+158:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8b0d55e02f54

If you have a user-defined Policy implementation that grants 
FilePermission on ${user.dir}/-, reading a file in the current directory 
using its base name will fail.  Still the same solution: Ensure that the 
path used in permission granting has the same style as the one how you 
access the file.

Setting -Djdk.security.filePermCompat=true will take you back to the 
jdk-9+140 behavior.
Setting -Djdk.io.permissionsUseCanonicalPath=true will take you back to 
the jdk8 behavior.
Feedback is welcome on jdk9-...@openjdk.java.net

Other areas of interest

  * JDK 9 Developer Guide [1]
  * JDK 9 Migration Guide [2]
  * JDK Cryptographic Roadmap [3]

Finaly, Dalibor and I gave a presentation at FOSDEM the video is 
available here [*4*]

Rgds,Rory

[1] http://docs.oracle.com/javase/9/javase-docs.htm
[2] 
https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4FB2-B34E-86D49B2E89B6
[3] https://www.java.com/en/jre-jdk-cryptoroadmap.html
[4] https://fosdem.org/2017/schedule/event/outreach/

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Announcing 2.0 release of the Hibernate Search plugins for Eclipse IDE

[Sanne Grinovero]

I'm very happy to announce that former Google Summer of Code student
Dmitry Bocharov, now a Red Hat employee working full time on Eclipse
tooling, has published an updated release of his initial GSOC project
!

More details and usage examples here:
 - http://in.relation.to/2017/03/03/EclipseToolsForHibernateSearchRelease20/

Regards,
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-10162 Inheritance and L2 cache

[Gail Badner]

Hi Christian,

I've added some comments to the PR.

As I mentioned there, this appears to be a partial fix. If the application
really requires the entity to implement the "correct" class, then this will
still break for them when the entity is not in the cache.

I'm not sure if a partial fix really suffices. IIUC, enhancement would work.

What to others think about this?

Regards,
Gail

On Thu, Mar 2, 2017 at 11:59 AM, Christian Beikov <
christian.bei...@gmail.com> wrote:

> I can, just wanted to hear some general opinions before creating the PR.
> Will do that tomorrow.
>
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 02.03.2017 um 20:57 schrieb Gail Badner:
> > Hi Christian,
> >
> > You mentioned that you reproduced the issue, but I don't see a test
> > case. Can you push your test case to a PR?
> >
> > Thanks,
> > Gail
> >
> > On Thu, Mar 2, 2017 at 10:15 AM, Steve Ebersole  > > wrote:
> >
> > BTW, regarding the Hip Chat "Dev" room, I'd personally not rely on
> > replies
> > from there.  E.g. I never saw your question there, and others
> > likely did
> > not either.  FWIW we had all agreed on a block of time when we
> > would try to
> > be available in that room specifically to discuss such things.
> > IIRC that
> > was roughly between 10 and 12 my time (central US).
> >
> > On Thu, Mar 2, 2017 at 12:08 PM Christian Beikov
> > mailto:christian.bei...@gmail.com>>
> > wrote:
> >
> > > Hey guys,
> > >
> > > Steve said I should start a discussion about the possible
> > solution for
> > > HHH-10162  > > so here we
> > > go.
> > >
> > > While debugging the issue, I found out that the proxy is created at
> > > DefaultLoadEventListener.createProxyIfNecessary() where it IMO
> > should
> > > consult the 2L cache first by calling existing =
> > > loadFromSecondLevelCache( event, persister, keyToLoad );. The
> > fix looks
> > > easy, but I am not sure of the implications. Obviously this will
> > affect
> > > performance a little since it has to consult the L2 cache now.
> > >
> > > I tried to start a discussion in the Dev room, but so far only
> > Andrea,
> > > Vlad and Chris have commented this. Has anyone a different idea for
> > > implementing this?
> > > --
> > >
> > > Mit freundlichen Grüßen,
> > >
> > 
> 
> > > *Christian Beikov*
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org  jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org 
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> >
> >
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-10162 Inheritance and L2 cache

[Christian Beikov]

Thanks for the comments, I have updated the PR.

I think that it is important to have a complete fix and I am already 
working on that, but this issue was specifically about the L2 cache, so 
I wanted to keep that stuff separate.

Here are some other polymorphism related issues:

  * https://hibernate.atlassian.net/browse/HHH-9845
  * https://hibernate.atlassian.net/browse/HHH-11280
  * https://hibernate.atlassian.net/browse/HHH-4742
  * https://hibernate.atlassian.net/browse/HHH-2927

The fix provided by Josh Landin for HHH-11280 would break reference 
equality and I think that is something we all want to keep. Which brings 
us to the actual problems.

1. Whenever we encounter an association that is of a polymorphic entity 
type, we should actually internally, regardless of what the user 
configures, always fetch that association with subtypes. Otherwise we 
could run into that same problem again, that we "pollute" the L1 cache 
with a proxy of the wrong type. Since we want to keep reference 
equality, we can't replace that instance.

2. When using bytecode enhancement, the loading of *ToOne instances 
could be deferred to the first access.

3. Actually it would also be possible if property access is used without 
bytecode enhancement, but that would require to use a special proxy for 
every object that might contain a non-initialized polymorphic 
association. The speciality about it is that it loads the association on 
first access.

4. Another thing that we should consider is "merging" of fetched state 
into existing instances of the L1 cache. Imagine a user loads an entity 
X and some of it's associations are lazy loaded. Then the user sets of a 
query that would fetch that association. Currently the associations will 
be left untouched because we skip any further processing as soon as we 
encounter the instance for X in the L1 cache. What we should actually do 
is, merge any fetched state into the instance if possible.

Since 1. will probably affect performance, it might only make sense to 
do it along with 2. or 3.

Regardless of these improvements, I think we should apply the L2 cache 
fix and handle the rest later.

What do you say?


Mit freundlichen Grüßen,

*Christian Beikov*
Am 04.03.2017 um 00:42 schrieb Gail Badner:
> Hi Christian,
>
> I've added some comments to the PR.
>
> As I mentioned there, this appears to be a partial fix. If the 
> application really requires the entity to implement the "correct" 
> class, then this will still break for them when the entity is not in 
> the cache.
>
> I'm not sure if a partial fix really suffices. IIUC, enhancement would 
> work.
>
> What to others think about this?
>
> Regards,
> Gail
>
> On Thu, Mar 2, 2017 at 11:59 AM, Christian Beikov 
> mailto:christian.bei...@gmail.com>> wrote:
>
> I can, just wanted to hear some general opinions before creating
> the PR.
> Will do that tomorrow.
>
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 02.03.2017 um 20:57 schrieb Gail Badner:
> > Hi Christian,
> >
> > You mentioned that you reproduced the issue, but I don't see a test
> > case. Can you push your test case to a PR?
> >
> > Thanks,
> > Gail
> >
> > On Thu, Mar 2, 2017 at 10:15 AM, Steve Ebersole
> mailto:st...@hibernate.org>
> > >> wrote:
> >
> > BTW, regarding the Hip Chat "Dev" room, I'd personally not
> rely on
> > replies
> > from there.  E.g. I never saw your question there, and others
> > likely did
> > not either.  FWIW we had all agreed on a block of time when we
> > would try to
> > be available in that room specifically to discuss such things.
> > IIRC that
> > was roughly between 10 and 12 my time (central US).
> >
> > On Thu, Mar 2, 2017 at 12:08 PM Christian Beikov
> >  
>  >>
> > wrote:
> >
> > > Hey guys,
> > >
> > > Steve said I should start a discussion about the possible
> > solution for
> > > HHH-10162
>  
> >  >> so here we
> > > go.
> > >
> > > While debugging the issue, I found out that the proxy is
> created at
> > > DefaultLoadEventListener.createProxyIfNecessary() where it IMO
> > should
> > > consult the 2L cache first by calling existing =
> > > loadFromSecondLevelCache( event, persister, keyToLoad );. The
>