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 <[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 RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/ jdo408 276-5638 mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
