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