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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
Patrick Linskey
202 669 5907
