Re: [PROPOSAL] PersistentFactory performance improvement

Michael Nash <[email protected]> Fri, 06 Aug 2004 12:30:56 -0400
Newsgroups gmane.comp.java.keel.user
Organization JGlobal Limited
Message-ID <1091809856.6205.330.camel__41821.8660787263$1091810836$gmane$org@monarch.workgroup>
gone....

These changes are now in CVS. All unit & functional tests show good -
but please let us know of any problems.

Mike

On Tue, 2004-08-03 at 16:12, Shash Chatterjee wrote:
> Going once, going twice.....
> 
> > All,
> > 
> > We have seen that in certain situations the Persistent factory (PF) 
> > components, for both default persistence and Hibernate, are being 
> > created many, many times.  These are heavyweight components, with a 
> > large penalty in CPU time and memory, whenever instantiated. 
> >  Currently, these are pooled components, but even so, too many are 
> > being created.  The proposal is to modify these two components to 
> > become singletons, as they originally were before securable 
> > persistents came to be. 
> > 
> > The downside of it is that this requires an  API change.  Currently, 
> > to check authorization, the PFs keep a copy of the user context (or, 
> > session, in Hibernate).  However, this makes it not possible for the 
> > PF to be a singleton, since you need a copy per user.  Instead, we 
> > can supply the context whenever a securable persistent needs to be 
> > created.  In other words, we currently do:
> > 
> > Persistent p = pf.create("myschema.mypersistent");
> > Persistent p = pf.create("myschema.mypersistent", transaction);
> > 
> > Instead, we will do:
> > 
> > Persistent p = pf.create("myschema.mypersistent", context);
> > Persistent p = pf.create("myschema.mypersistent", transaction, 
> > context);
> > 
> > This will change users' current code, but only if secured 
> > persistents are being used.  For "regular" persistents, the old API 
> > will still work.
> > 
> > The huge performance and memory usage gains are likely worth the 
> > backwards-incompatible API change, but feedback appreciated on if 
> > this is palatable to all who will be affected by the change!
> > 
> > Shash
> > _______________________________________________
> > User mailing list
> > [email protected]
> > http://lists.keelframework.org/listinfo.cgi/user-keelframework.org
> 
> 
> 
> _______________________________________________
> User mailing list
> [email protected]
> http://lists.keelframework.org/listinfo.cgi/user-keelframework.org