openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: unenhanced class support
Date Sun, 22 Jul 2007 19:51:27 GMT
> I think that no other implementation will have much of a better
> solution. So I don't see that we should try to exclude user options
> or a possible solution just because it's a poor performer.

What about eviction? My feeling is that wherever OpenJPA would
normally clear state (eviction, certain state transitions), we should
keep the state available instead when we can't intercept and reload on
demand.

-Patrick

On 7/21/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>
> On Jul 20, 2007, at 11:42 AM, Patrick Linskey wrote:
>
> > So, I'm looking for answers to the following questions in particular:
> >
> > 1. what should we do about { Java 5, no javaagent, field access }?
> > Should we support this configuration, including the corresponding
> > extra overhead, or should we require either property access or a
> > javaagent specified in these configurations?
>
> I think we should do EAGER fetching of fields just like the other
> implementations have to do.
> >
> > 2. what should we do about { Java 5, no javaagent, property access,
> > flushed | cleared instances }? There is a much lower impact to doing
> > the dirty tracking in these configurations, since the scope is
> > narrower. However, we might also be able to just not allow flush or
> > clear or multiple sequential transactions if the persistence context
> > has references to unenhanced, unredefined user-created instances.
>
> I think that no other implementation will have much of a better
> solution. So I don't see that we should try to exclude user options
> or a possible solution just because it's a poor performer.
>
> Craig
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>


-- 
Patrick Linskey
202 669 5907

Mime
View raw message