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 Tue, 24 Jul 2007 23:15:28 GMT
Hi,

I attached my current patch to OPENJPA-293. There are a number of open
issues in the patch marked by '#####' marks -- I'd appreciate another
set of eyes on those items in particular, and on the patch in general.

Aside from that, I'm planning to run the CTS without enhancement on at
some point in the next day or so, and want to get these changes
committed soon, so that we can start figuring out whether or not it
works.

-Patrick

On 7/22/07, Craig L Russell <Craig.Russell@sun.com> wrote:
> Hi Patrick,
>
> On Jul 22, 2007, at 12:51 PM, Patrick Linskey wrote:
>
> >> 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.
>
> Yes.
>
> Craig
> >
> > -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
>
> 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