Jon,
personally I agree 100%. I am using JDK 1.4.2 and have been doing so for quite a
while, but I am afraid that there is plenty of people out there that
suffer from company standards and the like .. :-(. Anyhow, I think we have found a way
to make such code available conditionally, such as e.g. a new
instance of TimeLimited that offers superior performance to the existing one.
Regards
Werner
PS I do not know how often to repeat myself on this list, but please no HTML emails to
this list .. ;-).
--Original Message Text---
From: Jon Wilmoth
Date: Sat, 3 Jul 2004 15:34:55 -0700 (PDT)
I for one, think it's a very acceptable compromise. (lazy loading performance gains
for a 1.3 runtime.
Werner Guttmann <[EMAIL PROTECTED]> wrote:
Stephen,
Not so sure here, as some committers are very keen to keep things 100% compatible with
JRE/JDK 1.2. Well, I think I am going to ask our users here
to get a full picture of the status quo.
Werner
On Fri, 2 Jul 2004 06:23:56 -0400, Stephen Ince wrote:
>
>Werner,
> The proxy interface approach looks clean and sound. I think 99% are
>using jdk 1.3 and up?
>
>Steve
>----- Original Message -----
>From: "Werner Guttmann"
>To:
>Sent: Thursday, July 01, 2004 5:41 PM
>Subject: Re: [castor-dev] JDO object creation performance flaw
>
>
>>
>> Stephen,
>>
>> I am still in the process of readying a first patch for this feature. In
>the meantime, I'd like to bounce the following iss! ue with you and everybody
>else
>> interested. It looks like the only way to go about a solution for this is
>via dynamic proxies. This implies that ...
>>
>> a) support for 1:1 lazy loading will only be available for people using
>JDK 1.3 and up.
>> b) I'll need to introduce a new requirement to get this working. For any
>class that you want to lazy load as part of a simple 1:1 relation, you'll
>need to
>> have an interface. I checked with other tools like OJB, as it looks like
>they have taken the same approach. Which comes as no surprise as dynamic
>> proxies depend on interfaces.
>>
>> FWIW
>> Werner
>>
>> On Thu, 1 Jul 2004 12:48:31 -0400, Stephen Ince wrote:
>>
>> >
>> >No problem about testing lazy-loading 1:1. This would of course help
>loading
>> >of large about objects.
>> >I w! ill work on a performance patch for top-level objects with large
>number
>> >of dependent children.
>> >----- Original Message -----
>> >From: "Werner Guttmann"
>> >To:
>> >Sent: Wednesday, June 30, 2004 4:47 AM
>> >Subject: Re: [castor-dev] JDO object creation performance flaw
>> >
>> >
>> >>
>> >> Well, if that's the case .. ;-), what would you think about helping us
>> >with testing new code, whether it's a feature such as support for
>> >lazy-loading 1:1
>> >> relations or support for the transient attribute at the level.
>Right
>> >now, I've got a patch posted for the transient support, and I'd be very
>> >interested to
>> >> get some hands-on comments.
>> >>
>> >> Interested ?
! >> >>
>> >> Werner
>> >>
>> >> On Tue, 29 Jun 2004 21:10:17 +0100, Gregory Block wrote:
>> >>
>> >> >
>> >> >On 29 Jun 2004, at 15:18, Stephen Ince wrote:
>> >> >> Steve --> I think it is an issue for 1:m relations and not for 1:1
>> >> >> relations.
>> >> >
>> >> >At this point, anything which can be done to offer the capability to
>> >> >fragment and delay queries is good; more importantly, if that partial
>> >> >loading then uses the cache, anything with 1:1 mappings where the
>other
>> >> >half of the 1 in question is shared by many should instantly see an
>> >> >improvement.
>> >> >
>> >> >So thumbs up on that lazy-load of 1:1, it's still good to see. :)
>> >> >
>> >> >
>> >> >
>> >> >-----------------------------------------------------------
>> >> >If you wish to unsubscribe from this mailing, send mail to
>> >> >[EMAIL PROTECTED] with a subject of:
>> >> > unsubscribe castor-dev
>> >> >
>> >>
>> >>
>> >>
>> >> -----------------------------------------------------------
>> >> If you wish to unsubscribe from this mailing, send mail to
>> >> [EMAIL PROTECTED] with a subject of:
>> >> unsubscribe castor-dev
>> >>
>> >
>> >
>> >
>> >-----------------------------------------------------------
>> >If you wish to unsubscribe from this mailing, send mail to
>> >[EMAIL PROTECTED] with a subject of:
>&!
gt; > unsubscribe castor-dev
>> >
>>
>>
>>
>> -----------------------------------------------------------
>> If you wish to unsubscribe from this mailing, send mail to
>> [EMAIL PROTECTED] with a subject of:
>> unsubscribe castor-dev
>>
>
>
>
>-----------------------------------------------------------
>If you wish to unsubscribe from this mailing, send mail to
>[EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
