The SessionFactory being Serialized outside the VM? Because otherwise it is already "serializable" via VM serialization hooks and org.hibernate.internal.SessionFactoryRegistry. And I'm not so convinced we should support serializing it for "out of" VM use aside from what we already do which assumes the new target VM has a similarly named SessionFactory in its org.hibernate.internal.SessionFactoryRegistry. On Wed, Jan 10, 2018 at 11:20 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; wrote: > Hi, > > While reviewing old PRs we have in the ORM project, I stumbled on this one > about serializing the SessionFactory. > > I created a new PR, rebased on top of the current master branch and all > tests are passing fine. > > If anyone wants to take a look, this is the PR: > > https://github.com/hibernate/hibernate-orm/pull/2107 > > I'm thinking we should integrate it in 5.3.Alpha and stabilize it if there > are some unforeseen changes. > > The only drawback is that, if we allow the SF to be Serializable, > upgrading > will be much more difficult in case we change object structure. > We could make it clear that this might not be supported or use the > serialVersionUID to point to Hibernate version: major.minor.patch. > > The main benefit is that, for a microservices architecture, Hibernate > could > start much faster this way. > > Vlad > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

I just don't see how serializing a full SessionFactory to disk is a good idea. What do you mean by "avoiding (caching) the DB metadata retrieving the part"?

On Thu, Jan 11, 2018 at 2:08 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; wrote: > Yes, out of the JVM. This PR allows the SF to be serialized to a file, so > the next time we bootstrap, we reload the whole SF from the file instead. > > There are many unforeseen issues probably related to this PR and it might > hurt maintenance in the long-run. > > For this reason, I'm going to leave the PR open as-is, and investigate > whether we can bootstrap faster by avoiding (cacahing) the DB metadata > retrieving the part. > > Vlad > > On Wed, Jan 10, 2018 at 7:45 PM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> The SessionFactory being Serialized outside the VM? Because otherwise it >> is already "serializable" via VM serialization hooks >> and org.hibernate.internal.SessionFactoryRegistry. And I'm not so >> convinced we should support serializing it for "out of" VM use aside from >> what we already do which assumes the new target VM has a similarly named >> SessionFactory in its org.hibernate.internal.SessionFactoryRegistry. >> >> On Wed, Jan 10, 2018 at 11:20 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; >> wrote: >> >>> Hi, >>> >>> While reviewing old PRs we have in the ORM project, I stumbled on this >>> one >>> about serializing the SessionFactory. >>> >>> I created a new PR, rebased on top of the current master branch and all >>> tests are passing fine. >>> >>> If anyone wants to take a look, this is the PR: >>> >>> https://github.com/hibernate/hibernate-orm/pull/2107 >>> >>> I'm thinking we should integrate it in 5.3.Alpha and stabilize it if >>> there >>> are some unforeseen changes. >>> >>> The only drawback is that, if we allow the SF to be Serializable, >>> upgrading >>> will be much more difficult in case we change object structure. >>> We could make it clear that this might not be supported or use the >>> serialVersionUID to point to Hibernate version: major.minor.patch. >>> >>> The main benefit is that, for a microservices architecture, Hibernate >>> could >>> start much faster this way. >>> >>> Vlad >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Sure, we need to profile it first.

From what our users have told us, getting the metadata from the database takes some time and my goal was to identify whether we can do something about that. I'll come back once I have more info.

Vlad On Thu, Jan 11, 2018 at 3:05 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > > On 11 January 2018 at 12:39, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > I just don't see how serializing a full SessionFactory to disk is a good > > idea. > > > > What do you mean by "avoiding (caching) the DB metadata retrieving the > > part"? > > I'm wondering too. I would be very cautious with that: if the > datasource connection is (temporarily) broken, because for example > Hibernate was restarted, we don't really know which assumptions will > still be true. The metadata is possibly no longer valid. > > You can't know for sure if the "development cycle" of the users isn't > including some step which makes changes to the database, or maybe even > updates it. I actually expect this to be common and this would cause a > lot of trouble. > > If we're willing to invest to make the ORM bootstrap faster, that's > great but we should work on identifying what is being slow and what > can be done without making it dangerous. > > > > > On Thu, Jan 11, 2018 at 2:08 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; > > wrote: > > > >> Yes, out of the JVM. This PR allows the SF to be serialized to a file, > >> so > >> the next time we bootstrap, we reload the whole SF from the file > >> instead. > >> > >> There are many unforeseen issues probably related to this PR and it > >> might > >> hurt maintenance in the long-run. > >> > >> For this reason, I'm going to leave the PR open as-is, and investigate > >> whether we can bootstrap faster by avoiding (cacahing) the DB metadata > >> retrieving the part. > >> > >> Vlad > >> > >> On Wed, Jan 10, 2018 at 7:45 PM, Steve Ebersole <steve(a)hibernate.org&gt; > >> wrote: > >> > >>> The SessionFactory being Serialized outside the VM? Because otherwise > >>> it > >>> is already "serializable" via VM serialization hooks > >>> and org.hibernate.internal.SessionFactoryRegistry. And I'm not so > >>> convinced we should support serializing it for "out of" VM use aside > >>> from > >>> what we already do which assumes the new target VM has a similarly > >>> named > >>> SessionFactory in its org.hibernate.internal.SessionFactoryRegistry. > >>> > >>> On Wed, Jan 10, 2018 at 11:20 AM Vlad Mihalcea > >>> <mihalcea.vlad(a)gmail.com&gt; > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> While reviewing old PRs we have in the ORM project, I stumbled on > >>>> this > >>>> one > >>>> about serializing the SessionFactory. > >>>> > >>>> I created a new PR, rebased on top of the current master branch and > >>>> all > >>>> tests are passing fine. > >>>> > >>>> If anyone wants to take a look, this is the PR: > >>>> > >>>> https://github.com/hibernate/hibernate-orm/pull/2107 > >>>> > >>>> I'm thinking we should integrate it in 5.3.Alpha and stabilize it if > >>>> there > >>>> are some unforeseen changes. > >>>> > >>>> The only drawback is that, if we allow the SF to be Serializable, > >>>> upgrading > >>>> will be much more difficult in case we change object structure. > >>>> We could make it clear that this might not be supported or use the > >>>> serialVersionUID to point to Hibernate version: major.minor.patch. > >>>> > >>>> The main benefit is that, for a microservices architecture, Hibernate > >>>> could > >>>> start much faster this way. > >>>> > >>>> Vlad > >>>> _______________________________________________ > >>>> hibernate-dev mailing list > >>>> hibernate-dev(a)lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>> > >>> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev