Should EntityManager#refresh retain an existing lock?
by Gail Badner
HHH-12257 involves refreshing an entity that is already has a pessimistic
lock. In the test case attached to the jira, EntityManager#refresh(Object
entity) is used to refresh the entity, instead of a method that specifies a
particular LockModetype (e.g., #refresh(Object entity, LockModeType
lockMode)). The lock on the refreshed entity is dropped.
A workaround is to determine the current lock mode using
Session#getCurrentLockMode, which returns a org.hibernate.LockMode object,
which can be converted to a LockModeType that can be used to call
EntityManager#refresh(Object entity, LockModeType lockMode).
Unfortunately, the code that converts org.hibernate.LockMode to
LockModeType is "internal" (org.hibernate.internal.util.LockModeConverter).
I'm on the fence about how this should work.
The API for EntityManager#refresh(Object entity) does not say that an
existing lock mode on the entity should be retained.
On the other hand, in JPA 2.1 spec, 3.4 Locking and Concurrency section
seems to indicate that locks on an entity apply to the transaction, and
does say that a lock on an entity should be dropped when refreshed without
an specified LockModeType.
Does anyone have any guidance on how this should work?
Thanks,
Gail
6 years, 10 months
ORM CI jobs - erroneous github triggers
by Steve Ebersole
The legacy ORM jobs (5.1-based ones at least) are getting triggered when
they should not be. Generally they all show they the run is triggered by a
"SCM change", but it does not show any changes. The underlying problem
(although I am at a loss as to why) is that there has indeed been SCM
changes pushed to Github, but against completely different branches. As
far as I can tell these job's Github setting are correct. Any ideas what
is going on?
This would not be such a big deal if the CI environment did not throttle
all waiting jobs down to one active job. So the jobs I am actually
interested in are forced to wait (sometimes over an hour) for these jobs
that should not even be running.
6 years, 10 months
Could we have a Hibernate 5.3 compatibility layer that includes the ORM 5.1 Hibernate Session class
by Scott Marlow
WildFly would like to have a version of 5.3+, that is compatible with ORM
5.1, with regard to the org.hibernate.session changes (including mapping of
exceptions thrown, so that the same exceptions are thrown).
Is it even possible to have an extra org.hibernate.Session interface + impl
(bridge) that matches the same session included in 5.1? The impl would
delegate to the real underlying org.hibernate.Session impl classes and also
wrap thrown exceptions, so that Hibernate 5.1 native ORM apps, continue to
work without code changes
Or something like that.
I could see how some users wouldn't want to use the compatibility layer to
avoid extra overhead, so in WildFly, we would have to make that possible
also.
What do you think?
We would need something similar in ORM 6.0+ that is also compatible with
5.1, if this is possible.
Scott
6 years, 10 months
5.3.0 release tomorrow
by Steve Ebersole
Wanted to remind everyone that tomorrow is the next time-boxed release for
5.3.
I wanted to get everyone's opinions about the version number, whether this
should be Beta2 or CR1. IMO It depends how you view the remaining
challenges with the JPA TCK, with CR1 being the optimistic view.
6 years, 10 months
Minor changes to the website
by Guillaume Smet
Hi,
Just so you know, I just made a few minor changes to the website:
- in the Releases dymanic submenu, you now have a label stating "latest
stable"/"development" to make it clearer what the versions are (it's
especially useful at this point of the ORM development for instance as 5.3
is the latest but not yet considered stable)
- I made the Documentation entry menu of ORM dynamic with a submenu
following the same principles as for Releases. It avoids going to the
latest then using the dropdown at the top (I kept the dropdown anyway)
In passing, I also added a placeholder page for the ORM 5.3 doc stating it
will be available soon.
HTH
--
Guillaume
6 years, 11 months
Hibernate ORM 5.2 backports
by Gail Badner
People seem to be relying on me to backport to 5.2. From a product
standpoint, there is no need to backport to 5.2 anymore once 5.3.0 is
released. Maybe 5.3.0 and 5.2.13 should be released together, with 5.2.13
being the last 5.2 release.
>From an earlier thread, it sounds like there is concern outside the ORM
team that we need to keep 5.2.x releases going for some time.
What is the criteria for backporting?
Steve, Andrea, and I had a brief discussion about backporting bugfixes from
master to 5.2 when the bugs apply to master. Is there more discussion to be
done about this?
FWIW, backporting to active community branches is everyone's
responsibility, not mine alone.
Regards,
Gail
6 years, 11 months
Plans to release 5.2.13?
by Gail Badner
We discussed stopping 5.2 releases at the F2F, but I can't remember what
was decided.
I see that there is a 5.2 branch. Should we be backporting to 5.2 branch?
Thanks,
Gail
6 years, 11 months
