the spec says:
"When instances are queried,
navigated to, or modified, instantiation of instances
and their fields and garbage collection
of unreferenced instances occurs without any explicit
control"
So that means that whatever implementation is used to
map between identity and Object, it can't be a hard
reference. So pojo's get garbage collected out of the
L1 cache. So that lends even more weight to your
statement that you need an L2 cache. Half the time the
implementation is going out to the DB to repopulate
the cache (like if you have a pojo and it's in a
wicket session that gets serialized, welll whoops, the
JDO implementation is going to query the DB to
repopulate the cache the when you deserialize and do
getObjectById).
--- Matej Knopp <[EMAIL PROTECTED]> wrote:
> I haven't profiled L2 caching done by database, if
> someone has I'd
> really be interested in results.
>
> Anyway, I wouldn't use WeakReference for caching,
> SoftReference seems to
> be better alternative.
>
> -Matej
>
> Geoff hendrey wrote:
> > No doubt L2 caching can speed up apps. Most
> databases
> > implement caching already. With L2 cache comes
> another
> > set of problems, and when you get deep enough into
> > them, you may wish you had not used the L2 cache,
> but
> > simply relied on effective caching in the
> database. On
> > the other hand, many L2 caching layers are out
> there,
> > and can be easily used with a pojo, whether the
> pojo
> > was retrieved by shades or not.
> >
> > WeakHashMap will discard your key/val pair during
> the
> > first garbage collection cycle after your program
> > holds no references to the key."An entry in a
> > WeakHashMap will automatically be removed when its
> key
> > is no longer in ordinary use"...from the javadoc.
> >
> >
> >
> > --- Matej Knopp <[EMAIL PROTECTED]> wrote:
> >
> >> I was more concerned about second level cache.
> When
> >> using loadable
> >> detachable models it is possible to hold only
> object
> >> id in session,
> >> loading the entire object on the beginning on
> >> request. In this scenario
> >> second level cache really helps. I think this is
> >> feature that lot of
> >> people would be missing.
> >>
> >> > If your application does not keep a reference
> >>> to the pojo, the pojo doesn't stay in the cache.
> >> What
> >>> kind of cache is that? :-)
> >> I think using soft references, the objects would
> be
> >> evicted only if out
> >> of memory is about to happen.
> >>
> >> -Matej
> >>
> >>> --- Matej Knopp <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> And how is caching done if you can't query
> >> objects
> >>>> by identity? Or does
> >>>> this question make even sense?
> >>>>
> >>>> -Matej
> >>>>
> >>>> Geoff hendrey wrote:
> >>>>> Ohh my god yes!!!!
> >>>>>
> >>>>> I ran into all these problems in JDOMax, and
> >> they
> >>>> are
> >>>>> all solved in Shades.
> >>>>>
> >>>>> I won't drop the name, but some very
> influential
> >>>>> person on EJB and JDO specs now believe that
> >>>> exposing
> >>>>> object identity in the form of API's was a
> >>>> mistake.
> >>>>> I agree -- you will notice shades has no
> methods
> >>>> to
> >>>>> retrieve an object by identity. Shades only
> has
> >>>>> queries.
> >>>>>
> >>>>> -geoff
> >>>>>
> >>>>>
> >>>>>
> >>>>> --- Igor Vaynberg <[EMAIL PROTECTED]>
> >> wrote:
> >>>>>> another interesting problem i find with
> >> identity
> >>>> in
> >>>>>> full blown orms is that
> >>>>>> it can cause a nasty cascade of loading
> object
> >>>> graph
> >>>>>> when using "business"
> >>>>>> identity instead of db identity.
> >>>>>>
> >>>>>> if you have school->semester->class
> >> relationships
> >>>>>> and you do not want to
> >>>>>> depend on db identity which is the
> >> "recommended"
> >>>> way
> >>>>>> most likely you will
> >>>>>> have
> >>>>>>
> >>>>>> class.equals(class other) {
> >>>>>> this.name.equals(other.name
> >>>>>> )&&this.semester.equals(other.semster); }
> >>>>>> semester.equals(semester other) {
> >>>>>> this.code.equals(other.code
> >>>>>> )&&this.school.equals(other.school); }
> >>>>>>
> >>>>>> so now every time you equals/hashcode a class
> >> you
> >>>>>> load the semester and the
> >>>>>> school. given they they are loaded-by-id and
> >>>> might
> >>>>>> be in 2nd level
> >>>>>> cache....but still. this is the kind of
> >> troubles
> >>>> you
> >>>>>> always have when
> >>>>>> working on such a highly abstracted level
> that
> >>>>>> doesnt always map properly to
> >>>>>> the bare metal.
> >>>>>>
> >>>>>> -Igor
> >>>>>>
> >>>>>>
> >>>>>> On 8/26/06, Geoff hendrey
> >>>> <[EMAIL PROTECTED]>
> >>>>>> wrote:
> >>>>>>> Sure - but honestly I don't want to convince
> >>>>>> anyone
> >>>>>>> they need Shades.
> >>>>>>>
> >>>>>>> One problem I found with JDO was that the
> >>>>>>> PersistenceManager was not serializable.
> >> Another
> >>>>>> is
> >>>>>>> that detachment had to be handled
> explicitely.
> >>>>>>>
> >>>>>>> In Shades all pojo's are inherently
> detached.
> >>>>>> Change
> >>>>>>> tracking is automagic. The DatabaseSession
> is
> >>>>>>> ultra-leightweight and totally appropriate
> for
> >>>>>> keeping
> >>>>>>> in a Session.
> >>>>>>>
> >>>>>>> A big innovation in Shades is how identity
> is
> >>>>>> handled
> >>>>>>> - that really solved a lot of problems for
> me
> >>>>>> related
> >>>>>>> to change of identity within transactions.
> >>>>>> Identity is
> >>>>>>> a much more fluid concept in Shades, due to
> >> the
> >>>>>>> dynamic ORMapping interface, which you can
> >> even
> >>>>>>> implement on the fly as an anonynmous inner
> >>>> class.
> >>>>>>> To be clear, I found ways to make JDO work
> >> just
> >>>>>> fine
> >>>>>>> with Wicket. Certainly JDO was a huge step
> >>>> forward
> >>>>>> in
> >>>>>>> making it easier to use Pojo-based
> frameworks
> >>>> like
> >>>>>>> Wicket.
> >>>>>>>
> >>>>>>> I blogged a bit on my motivation for Shades:
> >>>>>>> http://notskateboarding.blogspot.com/
> >>>>>>>
> >>>>>>> -geoff
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --- Igor Vaynberg <[EMAIL PROTECTED]>
> >>>> wrote:
> >>>>>>>> i glanced over the code - but i dont get it
> >>>>>> after
>
=== message truncated ===
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
