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
>>>>>> the first glance. perhaps
>>>>>> you can explain what difficulties you hit when
>>>> using
>>>>>> wicket and an orm to
>>>>>> help us better understand.
>>>>>>
>>>>>> seems to me like you are trying to work with a
>>>> ui
>>>>>> connected to a persistence
>>>>>> layer - without a service layer in between.
>> have
>>>> you
>>>>>> seen databinder which
>>>>>> glues wicket and hibernate together?
>>>>>>
>>>>>> also your point about wicket and tapestry -
>>>> wicket
>>>>>> is much more flexible
>>>>>> because it has IModel which gives you an extra
>>>> layer
>>>>>> of indirection that can
>>>>>> hide a lot of orm logic and make the code
>>>>>> cleaner/easier.
>>>>>>
>>>>>> -Igor
>>>>>>
>>>>>>
>>>>>> On 8/26/06, Geoff hendrey
>>>> <[EMAIL PROTECTED]>
>>>>>> wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I was one of the early users of Wicket before
>>>> 1.0.
>>>>>> I
>>>>>>> did a lot of work to use Wicket with my JDO
>>>>>>> implementation JDOMax (no longer supported).
>>>> In
>>>>>> the
>>>>>>> process I learned a lot about why it is harder
>>>>>> than it
>>>>>>> has to be to use many ORM frameworks with
>>>> Wicket
>>>>>> and
>>>>>>> Tapestry.
>>>>>>>
>>>>>>> I'm a member of JSR 243 Java Data Objects
>>>> Experts
>>>>>>> Group, and I advocated hard within that spec
>>>> for
>>>>>> the
>>>>>>> "fixing" of the JDO spec with regard to
>>>>>>> non-transaction-write behavior, along with
>>>> Eric
>>>>>> Samson
>>>>>>> and others. The JDO group was receptive,
>>>> having
>>>>>>> gotten similar feedback from Howard Lewis Ship
>>>> of
>>>>>>> Tapestry. I believe this change will benefit
>>>>>> Wicket
>>>>>>> users, and make it much easier to use JDO 2.0
>>>> than
>>>>>> JDO
>>>>>>> 1.1, from Wicket.
>>>>>>>
>>>>>>> However, I still wasn't satisfied that it was
>>>>>> "easy"
>>>>>>> to do ORM from Wicket or Tapestry. So I
>>>> started a
>>>>>> new
>>>>>>> project, based on what I learned -- it's a
>>>> better
>>>>>> way
>>>>>>> to do ORM -- I call it Shades. Following the
>>>>>> wicket
>>>>>>> style,Shades works without any XML
>>>> configuration.
>>>>>>> Rather than make this any longer-winded, I
>>>> thought
>>>>>> I
>>>>>>> would just begin passing back some code,
>>>> showing
> === 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
>
-------------------------------------------------------------------------
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
