You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-user@db.apache.org by Craig L Russell <Cr...@Sun.COM> on 2007/09/25 03:11:01 UTC
[DISCUSS] Evicting dirty instances
This topic was raised by Christiaan http://mail-archives.apache.org/
mod_mbox/db-jdo-user/200708.mbox/%3c12232225.post@talk.nabble.com%3e
Before the JDO spec introduced the concept of application-defined
flush(), the evict method could be used to make an instance hollow
and therefore subject to garbage collection.
When we introduced flush(), it became possible for all of the
application state in the cache to be erased from the cache, leaving
only the life-cycle state of the instance in memory for future
reference.
My proposal is to require that the JDO implementation treat flushed
dirty instances the same as hollow and persistent-nontransactional
instances, allowing them to be garbage collected. The uniqueness
guarantee only applies if the application itself holds a strong
reference to the instance.
This proposal would allow a well-designed program that creates or
updates a large transaction set of persistent instances to flush
periodically and not run out of memory.
If an application constructs a large number of instances and flushes
them, the only artifact remaining in the cache would be the memory
that the instance was new. That is, if the instance were subsequently
queried or obtained by id, the instance would still be persistent-new
although the instance retrieved might be a different Java instance
from the instance created and flushed.
We could still use the evict method to remove even the memory of the
life cycle state of the instance. So if the persistent-new instance
were flushed, it would still be persistent-new, but if it were then
evicted, it would be subsequently retrieved as a hollow or persistent-
nontransactional instance.
Please comment.
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [DISCUSS] Evicting dirty instances
Posted by Christiaan <ch...@hotmail.com>.
Hi,
any other ideas on this? Maybe a decision can be made for this topic?
kind regards,
Christiaan
--
View this message in context: http://www.nabble.com/-DISCUSS--Evicting-dirty-instances-tf4512750.html#a13644001
Sent from the JDO - Development mailing list archive at Nabble.com.
Re: [DISCUSS] Evicting dirty instances
Posted by Christiaan <ch...@hotmail.com>.
Not sure if this implied by your description, but should the be a mentioning
of the retainValues property. I would prefer it this is set to false, the
behaviour is exactly the same as commit, meaning that the object will
transition to hollow without an explicit evict().
kind regards,
Christiaan
--
View this message in context: http://www.nabble.com/-DISCUSS--Evicting-dirty-instances-tf4512749.html#a12997353
Sent from the JDO - User mailing list archive at Nabble.com.
Re: JDO TCK 2.0 - Which set of tests to use?
Posted by Michelle Caisse <Mi...@Sun.COM>.
Hi Ilan,
It looks like there are 49 cases in which this test is not finding the
expected method signature in your implementation. Within this group,
there are three cases.
- There are 26 instances in which the impl declares a method abstract
and the test expects a concrete method.
- There are 21 cases where the test finds a fully qualified method name
and is expecting an unqualified name, as in:
--- missing constructor:
expected: public .JDOCanRetryException(java.lang.String,
java.lang.Throwable[], java.lang.Object)
class: public class javax.jdo.JDOCanRetryException extends
javax.jdo.JDOException
--- non-standard, public member;
found: public javax.jdo.JDOCanRetryException(java.lang.String,
java.lang.Throwable[], java.lang.Object)
class: public class javax.jdo.JDOCanRetryException extends
javax.jdo.JDOException
- There are 2 cases involving the static keyword where there is no
difference between the expected and found.
--- missing method:
expected: public static java.lang.Object[]
getObjectIds(java.lang.Object[])
class: public class javax.jdo.JDOHelper extends java.lang.Object
--- non-standard, public member;
found: public static java.lang.Object[]
getObjectIds(java.lang.Object[])
class: public class javax.jdo.JDOHelper extends java.lang.Object
The first case looks like an implementation issue, the last a test
issue. There are also 6 different ClassNotFoundExceptions that look like
a test issue. Perhaps Martin or Craig could take a look at the test.
I've attached some output files that are easier to read than the original.
-- Michelle
Ilan Kirsh wrote:
> Hi Michelle,
>
> I also need help with test app-runonce. Probably something in my test
> environment is not configured well to pass this test, but I have no
> idea what is it.
> Attached the jdo jar file that I am using and the output of that test.
> Any clue?
>
> Regards, Ilan
>
Re: Vote: Remove/deprecate 'Implements' annotation and XML element
Posted by Matthew Adams <ma...@matthewadams.org>.
+!, f'shizzle, we need to remizzle & dizzepricate.
(I don't know why I wrote my comment using Snooplang.
I must be punchy after talking for 4 days straight.)
--- cbeams <cb...@gmail.com> wrote:
> I haven't fully reviewed this proposal, but I do
> know that using
> implements/@Implements only served to confuse me in
> the past. I kept
> thinking: isn't this information superfluous?
> Should the enhancer
> have been able to figure this stuff out by static
> analysis?
>
> So if it is in fact not needed, I'm a big +1.
>
> Thanks,
>
> - Chris Beams
>
> On Oct 12, 2007, at 8:45 AM, Craig L Russell wrote:
>
> > Hi Ilan,
> >
> > +1 to remove/deprecate the implements element and
> @Implements
> > annotation.
> >
> > If no adverse comments are received by Tuesday
> October 16, it's gone.
> >
> > On Oct 4, 2007, at 4:15 PM, Ilan Kirsh wrote:
> >
> >> Hi,
> >>
> >> The 'Implements' annotation (and the equivalent
> XML element)
> >> remind me
> >> the 'persistence-capable-superclass' XML
> attribute that is
> >> deprecated now.
> >
> > Yes, for JDO 1, we tried to have it possible to
> enhance classes
> > when not all of its dependencies (superclasses and
> implemented
> > interfaces) were available for loading and
> analysis. In this
> > environment, it was necessary to explicitly
> declare which
> > interfaces were implemented because you could not
> load all of the
> > directly implemented interfaces to see which
> persistence-capable
> > interfaces were indirectly inherited.
> >
> > But now, enhancement requires access to the entire
> inheritance tree
> > and it makes sense to also require the implements
> tree as well.
> >>
> >> If persistence capable interfaces are marked as
> such by annotations
> >> (or in the XML metadata), why should we have this
> duplication?
> >>
> >> Implementations should be able to find
> implemented persistence
> >> capable
> >> interfaces as they find a super persistence
> capable class.
> >
> > True, and I support deprecating the xml attribute
> and removing the
> > @Implements annotation.
> >
> > Unless someone can justify why there would be any
> semantic
> > difference between explicitly declaring the
> interfaces versus the
> > enhancer finding them. The only thing I can think
> of is whether an
> > explicitly named interface would have an extent
> managed, but I
> > think that you can only query over the extent of
> classes/interfaces
> > that themselves declare that an extent is managed.
> >
> > Craig
> >>
> >> Ilan Kirsh
> >> ObjectDB Software
> >> http://www.objectdb.com
> >>
> >>
> >
> > Craig Russell
> > Architect, Sun Java Enterprise System
> http://java.sun.com/products/jdo
> > 408 276-5638 mailto:Craig.Russell@sun.com
> > P.S. A good JDO? O, Gasp!
> >
>
>
Re: Vote: Remove/deprecate 'Implements' annotation and XML element
Posted by cbeams <cb...@gmail.com>.
I haven't fully reviewed this proposal, but I do know that using
implements/@Implements only served to confuse me in the past. I kept
thinking: isn't this information superfluous? Should the enhancer
have been able to figure this stuff out by static analysis?
So if it is in fact not needed, I'm a big +1.
Thanks,
- Chris Beams
On Oct 12, 2007, at 8:45 AM, Craig L Russell wrote:
> Hi Ilan,
>
> +1 to remove/deprecate the implements element and @Implements
> annotation.
>
> If no adverse comments are received by Tuesday October 16, it's gone.
>
> On Oct 4, 2007, at 4:15 PM, Ilan Kirsh wrote:
>
>> Hi,
>>
>> The 'Implements' annotation (and the equivalent XML element)
>> remind me
>> the 'persistence-capable-superclass' XML attribute that is
>> deprecated now.
>
> Yes, for JDO 1, we tried to have it possible to enhance classes
> when not all of its dependencies (superclasses and implemented
> interfaces) were available for loading and analysis. In this
> environment, it was necessary to explicitly declare which
> interfaces were implemented because you could not load all of the
> directly implemented interfaces to see which persistence-capable
> interfaces were indirectly inherited.
>
> But now, enhancement requires access to the entire inheritance tree
> and it makes sense to also require the implements tree as well.
>>
>> If persistence capable interfaces are marked as such by annotations
>> (or in the XML metadata), why should we have this duplication?
>>
>> Implementations should be able to find implemented persistence
>> capable
>> interfaces as they find a super persistence capable class.
>
> True, and I support deprecating the xml attribute and removing the
> @Implements annotation.
>
> Unless someone can justify why there would be any semantic
> difference between explicitly declaring the interfaces versus the
> enhancer finding them. The only thing I can think of is whether an
> explicitly named interface would have an extent managed, but I
> think that you can only query over the extent of classes/interfaces
> that themselves declare that an extent is managed.
>
> Craig
>>
>> Ilan Kirsh
>> ObjectDB Software
>> http://www.objectdb.com
>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Vote: Remove/deprecate 'Implements' annotation and XML element
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Ilan,
+1 to remove/deprecate the implements element and @Implements
annotation.
If no adverse comments are received by Tuesday October 16, it's gone.
On Oct 4, 2007, at 4:15 PM, Ilan Kirsh wrote:
> Hi,
>
> The 'Implements' annotation (and the equivalent XML element) remind me
> the 'persistence-capable-superclass' XML attribute that is
> deprecated now.
Yes, for JDO 1, we tried to have it possible to enhance classes when
not all of its dependencies (superclasses and implemented interfaces)
were available for loading and analysis. In this environment, it was
necessary to explicitly declare which interfaces were implemented
because you could not load all of the directly implemented interfaces
to see which persistence-capable interfaces were indirectly inherited.
But now, enhancement requires access to the entire inheritance tree
and it makes sense to also require the implements tree as well.
>
> If persistence capable interfaces are marked as such by annotations
> (or in the XML metadata), why should we have this duplication?
>
> Implementations should be able to find implemented persistence capable
> interfaces as they find a super persistence capable class.
True, and I support deprecating the xml attribute and removing the
@Implements annotation.
Unless someone can justify why there would be any semantic difference
between explicitly declaring the interfaces versus the enhancer
finding them. The only thing I can think of is whether an explicitly
named interface would have an extent managed, but I think that you
can only query over the extent of classes/interfaces that themselves
declare that an extent is managed.
Craig
>
> Ilan Kirsh
> ObjectDB Software
> http://www.objectdb.com
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
'Implements' annotation and XML element
Posted by Ilan Kirsh <ki...@objectdb.com>.
Hi,
The 'Implements' annotation (and the equivalent XML element) remind me
the 'persistence-capable-superclass' XML attribute that is deprecated now.
If persistence capable interfaces are marked as such by annotations
(or in the XML metadata), why should we have this duplication?
Implementations should be able to find implemented persistence capable
interfaces as they find a super persistence capable class.
Ilan Kirsh
ObjectDB Software
http://www.objectdb.com
Re: JDO TCK 2.0 - Which set of tests to use?
Posted by Michelle Caisse <Mi...@Sun.COM>.
You'll have to enter a challenge on those and we'll back port the
changes to a 2.0.x branch or add the test to the exclude list.
To initiate a challenge "send email to: jdo-dev@db.apache.org
<ma...@db.apache.org> with a subject line containing
"CHALLENGE" and the name of the test program, e.g.
org.apache.jdo.tck.api.persistencemanager.ThreadSafe.java; and the body
of the email containing the details of the challenge." You can just
reference the JIRAs for the details.
Thanks,
Michelle
Ilan Kirsh wrote:
> Hi Michelle,
>
> That was very helpful. Running this branch looks much better.
>
> Still I have problems with the following tests:
>
> 1. FetchPlanInterface.testGroups (fixed in JDO-402, after 2.0.1?)
> 2. ResultClassRequirements.testNegative (fixed in JDO-524)
> 3. ChangeQuery.testPositive (fixed in JDO-529)
> 4. ImplicitParameters.testGrouping (fixed in JDO-530)
> 5. StateTransitionsReturnedObjects (JDO-513, JDO-514).
>
> Please advise.
>
> Thanks, Ilan
>
>
> ----- Original Message ----- From: "Michelle Caisse"
> <Mi...@Sun.COM>
> To: <jd...@db.apache.org>
> Cc: "JDO Expert Group" <jd...@Sun.COM>
> Sent: Tuesday, September 25, 2007 8:46 PM
> Subject: Re: JDO TCK 2.0 - Which set of tests to use?
>
>
>> Hi Ilan,
>>
>> There is a source branch 2.01 with changes responsive to some earlier
>> challenges. There's a wiki page documenting the issues
>> http://wiki.apache.org/jdo/TCKChallenges. Please get this branch from
>> svn
>> and let us know if there are remaining issues.
>>
>> Thanks,
>> Michelle
>>
>> Ilan Kirsh wrote:
>>> Is there an approved exclude list for the original JDO 2 TCK 2.0
>>> that is more realistic than the bundled list of 2 enhancement tests?
>>>
>>> If not, when ready, I can publish my exclude list as a suggestion.
>>>
>>> Regards, Ilan
>>>
>>> ----- Original Message ----- From: Craig L Russell To: JDO
>>> Expert Group Cc: Apache JDO project Sent:
>>> Tuesday, September 25, 2007 7:32 PM
>>> Subject: Re: JDO TCK 2.0 - Which set of tests to use?
>>>
>>>
>>> Hi Ilan,
>>>
>>>
>>>
>>>
>>> On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:
>>>
>>>
>>> Hi,
>>>
>>> The JDO 2 TCK 2.0 package that is available for download at:
>>> http://db.apache.org/jdo/releases/release-2.0.cgi
>>> contains many invalid tests that have been fixed since that
>>> release.
>>>
>>>
>>> Correct. The latest trunk has updated tests.
>>>
>>>
>>> In order to claim compliance with JDO 2 should I use the tests at:
>>> http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
>>>
>>>
>>> Well, there's no official release of the JDO 2.1 test suite, so
>>> probably to claim compliance with JDO 2.0, you should update the
>>> exclude
>>> list and run the original tests. And you should take a look at the tck2
>>> project as well.
>>>
>>>
>>> Should I fill CHALLENGE against tests in that set that IMO are
>>> invalid?
>>>
>>>
>>> Yes. We still have time to fix these before official release.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Thank you for your continued support.
>>>
>>>
>>> Craig
>>>
>>>
>>> Ilan Kirsh
>>> ObjectDB Software
>>>
>>>
>>>
>>>
>>> Craig Russell
>>>
>>> Architect, Sun Java Enterprise System
>>> http://java.sun.com/products/jdo
>>>
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>>
>>>
>>
>
>
Re: JDO TCK 2.0 - Which set of tests to use?
Posted by Ilan Kirsh <ki...@objectdb.com>.
Hi Michelle,
That was very helpful. Running this branch looks much better.
Still I have problems with the following tests:
1. FetchPlanInterface.testGroups (fixed in JDO-402, after 2.0.1?)
2. ResultClassRequirements.testNegative (fixed in JDO-524)
3. ChangeQuery.testPositive (fixed in JDO-529)
4. ImplicitParameters.testGrouping (fixed in JDO-530)
5. StateTransitionsReturnedObjects (JDO-513, JDO-514).
Please advise.
Thanks, Ilan
----- Original Message -----
From: "Michelle Caisse" <Mi...@Sun.COM>
To: <jd...@db.apache.org>
Cc: "JDO Expert Group" <jd...@Sun.COM>
Sent: Tuesday, September 25, 2007 8:46 PM
Subject: Re: JDO TCK 2.0 - Which set of tests to use?
> Hi Ilan,
>
> There is a source branch 2.01 with changes responsive to some earlier
> challenges. There's a wiki page documenting the issues
> http://wiki.apache.org/jdo/TCKChallenges. Please get this branch from svn
> and let us know if there are remaining issues.
>
> Thanks,
> Michelle
>
> Ilan Kirsh wrote:
>> Is there an approved exclude list for the original JDO 2 TCK 2.0
>> that is more realistic than the bundled list of 2 enhancement tests?
>>
>> If not, when ready, I can publish my exclude list as a suggestion.
>>
>> Regards, Ilan
>>
>> ----- Original Message -----
>> From: Craig L Russell To: JDO Expert Group Cc: Apache JDO project Sent:
>> Tuesday, September 25, 2007 7:32 PM
>> Subject: Re: JDO TCK 2.0 - Which set of tests to use?
>>
>>
>> Hi Ilan,
>>
>>
>>
>>
>> On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:
>>
>>
>> Hi,
>>
>> The JDO 2 TCK 2.0 package that is available for download at:
>> http://db.apache.org/jdo/releases/release-2.0.cgi
>> contains many invalid tests that have been fixed since that release.
>>
>>
>> Correct. The latest trunk has updated tests.
>>
>>
>> In order to claim compliance with JDO 2 should I use the tests at:
>> http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
>>
>>
>> Well, there's no official release of the JDO 2.1 test suite, so
>> probably to claim compliance with JDO 2.0, you should update the exclude
>> list and run the original tests. And you should take a look at the tck2
>> project as well.
>>
>>
>> Should I fill CHALLENGE against tests in that set that IMO are
>> invalid?
>>
>>
>> Yes. We still have time to fix these before official release.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Thank you for your continued support.
>>
>>
>> Craig
>>
>>
>> Ilan Kirsh
>> ObjectDB Software
>>
>>
>>
>>
>> Craig Russell
>>
>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>
>> 408 276-5638 mailto:Craig.Russell@sun.com
>>
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>>
>
Re: JDO TCK 2.0 - Which set of tests to use?
Posted by Michelle Caisse <Mi...@Sun.COM>.
Hi Ilan,
There is a source branch 2.01 with changes responsive to some earlier
challenges. There's a wiki page documenting the issues
http://wiki.apache.org/jdo/TCKChallenges. Please get this branch from
svn and let us know if there are remaining issues.
Thanks,
Michelle
Ilan Kirsh wrote:
> Is there an approved exclude list for the original JDO 2 TCK 2.0
> that is more realistic than the bundled list of 2 enhancement tests?
>
> If not, when ready, I can publish my exclude list as a suggestion.
>
> Regards, Ilan
>
> ----- Original Message -----
> From: Craig L Russell
> To: JDO Expert Group
> Cc: Apache JDO project
> Sent: Tuesday, September 25, 2007 7:32 PM
> Subject: Re: JDO TCK 2.0 - Which set of tests to use?
>
>
> Hi Ilan,
>
>
>
>
> On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:
>
>
> Hi,
>
> The JDO 2 TCK 2.0 package that is available for download at:
> http://db.apache.org/jdo/releases/release-2.0.cgi
> contains many invalid tests that have been fixed since that release.
>
>
> Correct. The latest trunk has updated tests.
>
>
> In order to claim compliance with JDO 2 should I use the tests at:
> http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
>
>
> Well, there's no official release of the JDO 2.1 test suite, so probably to claim compliance with JDO 2.0, you should update the exclude list and run the original tests. And you should take a look at the tck2 project as well.
>
>
> Should I fill CHALLENGE against tests in that set that IMO are invalid?
>
>
> Yes. We still have time to fix these before official release.
>
>
>
> Thanks,
>
>
>
> Thank you for your continued support.
>
>
> Craig
>
>
> Ilan Kirsh
> ObjectDB Software
>
>
>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>
>
>
Re: JDO TCK 2.0 - Which set of tests to use?
Posted by Ilan Kirsh <ki...@objectdb.com>.
Is there an approved exclude list for the original JDO 2 TCK 2.0
that is more realistic than the bundled list of 2 enhancement tests?
If not, when ready, I can publish my exclude list as a suggestion.
Regards, Ilan
----- Original Message -----
From: Craig L Russell
To: JDO Expert Group
Cc: Apache JDO project
Sent: Tuesday, September 25, 2007 7:32 PM
Subject: Re: JDO TCK 2.0 - Which set of tests to use?
Hi Ilan,
On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:
Hi,
The JDO 2 TCK 2.0 package that is available for download at:
http://db.apache.org/jdo/releases/release-2.0.cgi
contains many invalid tests that have been fixed since that release.
Correct. The latest trunk has updated tests.
In order to claim compliance with JDO 2 should I use the tests at:
http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
Well, there's no official release of the JDO 2.1 test suite, so probably to claim compliance with JDO 2.0, you should update the exclude list and run the original tests. And you should take a look at the tck2 project as well.
Should I fill CHALLENGE against tests in that set that IMO are invalid?
Yes. We still have time to fix these before official release.
Thanks,
Thank you for your continued support.
Craig
Ilan Kirsh
ObjectDB Software
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Persistence Capable Interfaces and Abstract Classes
Posted by cbeams <cb...@gmail.com>.
Okay, thanks. At any rate, I want this simple functionality from
newQuery(Type.class) where Type is a PC interface. Hope this makes
sense.
- Chris
On Sep 27, 2007, at 5:19 PM, Ilan Kirsh wrote:
> Hi Chris,
>
> Actually you need to use Extent to exclude subclasses. To include
> subclasses
> you can use a candidate class, as described in section 14.6:
>
> If the candidates are not specified explicitly by newQuery,
> setCandidates(Collection), or setCandidates(Extent), then the
> candidate
> extent is the extent of instances of the candidate class in the
> datastore
> including subclasses. That is, the candidates are the result of
> getPersistenceManager().getExtent(candidateClass, true).
>
> Regards, Ilan
>
> ----- Original Message ----- From: "cbeams" <cb...@gmail.com>
> To: <jd...@db.apache.org>
> Cc: "Craig L Russell" <Cr...@Sun.COM>; "JDO Expert Group"
> <jd...@Sun.COM>
> Sent: Friday, September 28, 2007 1:35 AM
> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>
>
>> As we continue considering what Persistent Interfaces are really all
>> about in the 2.1 timeline, let me reiterate my original need /
>> expectation with this:
>>
>> If I have a PC class MyPerson that implements persistent interface
>> Person:
>>
>> public class Person {}
>> public class MyPerson implements Person {}
>>
>>
>> I expect that I should be able to query by the person interface and
>> retrieve all persistent instances of objects assignable to that
>> interface:
>>
>> List<Person> people = (List<Person>) pm.newQuery
>> (Person.class).execute();
>>
>> Note here that I'm not using an Extent. Typically, to return
>> subtypes, we would need to do something like:
>>
>> pm.newQuery(new Extent(Person.class, true)); //...
>>
>> However, this makes no sense when the type in question is an
>> interface. Thus I propose that queries taking interfaces as
>> parameters implicitly return all implementing persistent instances.
>>
>> I believe that this scenario represents the most basic, intuitive
>> kind of use case possible when dealing with interfaces. And, it is
>> currently not supported.
>>
>> Note that what I'm talking about here does not take into account any
>> of the support for implementation generation (pm.newInstance()),
>> etc.. I consider all that functionality, while perhaps useful, to be
>> much more advanced.
>>
>> Thanks,
>>
>> - Chris
>>
>> Chris Beams
>>
>>
>> On Sep 27, 2007, at 2:55 PM, Ilan Kirsh wrote:
>>
>>> Thanks. It might be appropriate to mention persistent interfaces
>>> also in chapter 6.
>>>
>>> Ilan
>>> ----- Original Message -----
>>> From: Craig L Russell
>>> To: Ilan Kirsh
>>> Cc: jdo-dev@db.apache.org ; JDO Expert Group
>>> Sent: Wednesday, September 26, 2007 6:00 PM
>>> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>>>
>>> Hi Ilan,
>>>
>>> You could start with the pm.newInstance method in 12.6.6 that is
>>> the way to instantiate the instances, and then look at the metadata
>>> descriptions in 18.5.
>>>
>>> Craig
>>>
>>> On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
>>>
>>>> I wonder where in the spec persistence capable interfaces and
>>>> persistence capable abstract classes are discussed.
>>>> I have the Java Data Objects 2.1 specification draft from 13 June
>>>> 2007, and it seems that relevant sections (e.g. chapter 6) ignore
>>>> this issue.
>>>>
>>>> Ilan
>>>>
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>> products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>
>>
>
>
Re: Persistence Capable Interfaces and Abstract Classes
Posted by Ilan Kirsh <ki...@objectdb.com>.
Hi Chris,
Actually you need to use Extent to exclude subclasses. To include subclasses
you can use a candidate class, as described in section 14.6:
If the candidates are not specified explicitly by newQuery,
setCandidates(Collection), or setCandidates(Extent), then the candidate
extent is the extent of instances of the candidate class in the datastore
including subclasses. That is, the candidates are the result of
getPersistenceManager().getExtent(candidateClass, true).
Regards, Ilan
----- Original Message -----
From: "cbeams" <cb...@gmail.com>
To: <jd...@db.apache.org>
Cc: "Craig L Russell" <Cr...@Sun.COM>; "JDO Expert Group"
<jd...@Sun.COM>
Sent: Friday, September 28, 2007 1:35 AM
Subject: Re: Persistence Capable Interfaces and Abstract Classes
> As we continue considering what Persistent Interfaces are really all
> about in the 2.1 timeline, let me reiterate my original need /
> expectation with this:
>
> If I have a PC class MyPerson that implements persistent interface
> Person:
>
> public class Person {}
> public class MyPerson implements Person {}
>
>
> I expect that I should be able to query by the person interface and
> retrieve all persistent instances of objects assignable to that
> interface:
>
> List<Person> people = (List<Person>) pm.newQuery
> (Person.class).execute();
>
> Note here that I'm not using an Extent. Typically, to return
> subtypes, we would need to do something like:
>
> pm.newQuery(new Extent(Person.class, true)); //...
>
> However, this makes no sense when the type in question is an
> interface. Thus I propose that queries taking interfaces as
> parameters implicitly return all implementing persistent instances.
>
> I believe that this scenario represents the most basic, intuitive
> kind of use case possible when dealing with interfaces. And, it is
> currently not supported.
>
> Note that what I'm talking about here does not take into account any
> of the support for implementation generation (pm.newInstance()),
> etc.. I consider all that functionality, while perhaps useful, to be
> much more advanced.
>
> Thanks,
>
> - Chris
>
> Chris Beams
>
>
> On Sep 27, 2007, at 2:55 PM, Ilan Kirsh wrote:
>
>> Thanks. It might be appropriate to mention persistent interfaces
>> also in chapter 6.
>>
>> Ilan
>> ----- Original Message -----
>> From: Craig L Russell
>> To: Ilan Kirsh
>> Cc: jdo-dev@db.apache.org ; JDO Expert Group
>> Sent: Wednesday, September 26, 2007 6:00 PM
>> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>>
>> Hi Ilan,
>>
>> You could start with the pm.newInstance method in 12.6.6 that is
>> the way to instantiate the instances, and then look at the metadata
>> descriptions in 18.5.
>>
>> Craig
>>
>> On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
>>
>>> I wonder where in the spec persistence capable interfaces and
>>> persistence capable abstract classes are discussed.
>>> I have the Java Data Objects 2.1 specification draft from 13 June
>>> 2007, and it seems that relevant sections (e.g. chapter 6) ignore
>>> this issue.
>>>
>>> Ilan
>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>
>
Re: Persistence Capable Interfaces and Abstract Classes
Posted by cbeams <cb...@gmail.com>.
As we continue considering what Persistent Interfaces are really all
about in the 2.1 timeline, let me reiterate my original need /
expectation with this:
If I have a PC class MyPerson that implements persistent interface
Person:
public class Person {}
public class MyPerson implements Person {}
I expect that I should be able to query by the person interface and
retrieve all persistent instances of objects assignable to that
interface:
List<Person> people = (List<Person>) pm.newQuery
(Person.class).execute();
Note here that I'm not using an Extent. Typically, to return
subtypes, we would need to do something like:
pm.newQuery(new Extent(Person.class, true)); //...
However, this makes no sense when the type in question is an
interface. Thus I propose that queries taking interfaces as
parameters implicitly return all implementing persistent instances.
I believe that this scenario represents the most basic, intuitive
kind of use case possible when dealing with interfaces. And, it is
currently not supported.
Note that what I'm talking about here does not take into account any
of the support for implementation generation (pm.newInstance()),
etc.. I consider all that functionality, while perhaps useful, to be
much more advanced.
Thanks,
- Chris
Chris Beams
On Sep 27, 2007, at 2:55 PM, Ilan Kirsh wrote:
> Thanks. It might be appropriate to mention persistent interfaces
> also in chapter 6.
>
> Ilan
> ----- Original Message -----
> From: Craig L Russell
> To: Ilan Kirsh
> Cc: jdo-dev@db.apache.org ; JDO Expert Group
> Sent: Wednesday, September 26, 2007 6:00 PM
> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>
> Hi Ilan,
>
> You could start with the pm.newInstance method in 12.6.6 that is
> the way to instantiate the instances, and then look at the metadata
> descriptions in 18.5.
>
> Craig
>
> On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
>
>> I wonder where in the spec persistence capable interfaces and
>> persistence capable abstract classes are discussed.
>> I have the Java Data Objects 2.1 specification draft from 13 June
>> 2007, and it seems that relevant sections (e.g. chapter 6) ignore
>> this issue.
>>
>> Ilan
>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Re: Persistence Capable Interfaces and Abstract Classes
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Ilan,
Good point. Persistent interfaces is on my list to discuss in the
spec, and I'll add Abstract Classes as a topic in the same light.
Craig
On Sep 27, 2007, at 2:55 PM, Ilan Kirsh wrote:
> Thanks. It might be appropriate to mention persistent interfaces
> also in chapter 6.
>
> Ilan
> ----- Original Message -----
> From: Craig L Russell
> To: Ilan Kirsh
> Cc: jdo-dev@db.apache.org ; JDO Expert Group
> Sent: Wednesday, September 26, 2007 6:00 PM
> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>
> Hi Ilan,
>
> You could start with the pm.newInstance method in 12.6.6 that is
> the way to instantiate the instances, and then look at the metadata
> descriptions in 18.5.
>
> Craig
>
> On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
>
>> I wonder where in the spec persistence capable interfaces and
>> persistence capable abstract classes are discussed.
>> I have the Java Data Objects 2.1 specification draft from 13 June
>> 2007, and it seems that relevant sections (e.g. chapter 6) ignore
>> this issue.
>>
>> Ilan
>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Persistence Capable Interfaces and Abstract Classes
Posted by Ilan Kirsh <ki...@objectdb.com>.
Thanks. It might be appropriate to mention persistent interfaces also in chapter 6.
Ilan
----- Original Message -----
From: Craig L Russell
To: Ilan Kirsh
Cc: jdo-dev@db.apache.org ; JDO Expert Group
Sent: Wednesday, September 26, 2007 6:00 PM
Subject: Re: Persistence Capable Interfaces and Abstract Classes
Hi Ilan,
You could start with the pm.newInstance method in 12.6.6 that is the way to instantiate the instances, and then look at the metadata descriptions in 18.5.
Craig
On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
I wonder where in the spec persistence capable interfaces and persistence capable abstract classes are discussed.
I have the Java Data Objects 2.1 specification draft from 13 June 2007, and it seems that relevant sections (e.g. chapter 6) ignore this issue.
Ilan
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Persistence Capable Interfaces and Abstract Classes
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Ilan,
You could start with the pm.newInstance method in 12.6.6 that is the
way to instantiate the instances, and then look at the metadata
descriptions in 18.5.
Craig
On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
> I wonder where in the spec persistence capable interfaces and
> persistence capable abstract classes are discussed.
> I have the Java Data Objects 2.1 specification draft from 13 June
> 2007, and it seems that relevant sections (e.g. chapter 6) ignore
> this issue.
>
> Ilan
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Persistence Capable Interfaces and Abstract Classes
Posted by Ilan Kirsh <ki...@objectdb.com>.
I wonder where in the spec persistence capable interfaces and persistence capable abstract classes are discussed.
I have the Java Data Objects 2.1 specification draft from 13 June 2007, and it seems that relevant sections (e.g. chapter 6) ignore this issue.
Ilan
Re: JDO TCK 2.0 - Which set of tests to use?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Ilan,
On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:
> Hi,
>
> The JDO 2 TCK 2.0 package that is available for download at:
> http://db.apache.org/jdo/releases/release-2.0.cgi
> contains many invalid tests that have been fixed since that release.
Correct. The latest trunk has updated tests.
>
> In order to claim compliance with JDO 2 should I use the tests at:
> http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
Well, there's no official release of the JDO 2.1 test suite, so
probably to claim compliance with JDO 2.0, you should update the
exclude list and run the original tests. And you should take a look
at the tck2 project as well.
>
> Should I fill CHALLENGE against tests in that set that IMO are
> invalid?
Yes. We still have time to fix these before official release.
>
> Thanks,
>
Thank you for your continued support.
Craig
> Ilan Kirsh
> ObjectDB Software
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
JDO TCK 2.0 - Which set of tests to use?
Posted by Ilan Kirsh <ki...@objectdb.com>.
Hi,
The JDO 2 TCK 2.0 package that is available for download at:
http://db.apache.org/jdo/releases/release-2.0.cgi
contains many invalid tests that have been fixed since that release.
In order to claim compliance with JDO 2 should I use the tests at:
http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
Should I fill CHALLENGE against tests in that set that IMO are invalid?
Thanks,
Ilan Kirsh
ObjectDB Software
Re: [DISCUSS] Evicting dirty instances
Posted by Ilan Kirsh <ki...@objectdb.com>.
I think that it is a good idea. If datastore locking was not supported I
would even think discarding also object states as done in commit (to be
consistent with JPA flush), but it might cause problems when using datastore
locking.
----- Original Message -----
From: "Craig L Russell" <Cr...@Sun.COM>
To: "JDO Expert Group" <jd...@Sun.COM>; "Apache JDO project"
<jd...@db.apache.org>; "Christiaan" <ch...@hotmail.com>;
<jd...@db.apache.org>
Sent: Tuesday, September 25, 2007 3:11 AM
Subject: [DISCUSS] Evicting dirty instances
> This topic was raised by Christiaan http://mail-archives.apache.org/
> mod_mbox/db-jdo-user/200708.mbox/%3c12232225.post@talk.nabble.com%3e
>
> Before the JDO spec introduced the concept of application-defined
> flush(), the evict method could be used to make an instance hollow and
> therefore subject to garbage collection.
>
> When we introduced flush(), it became possible for all of the application
> state in the cache to be erased from the cache, leaving only the
> life-cycle state of the instance in memory for future reference.
>
> My proposal is to require that the JDO implementation treat flushed dirty
> instances the same as hollow and persistent-nontransactional instances,
> allowing them to be garbage collected. The uniqueness guarantee only
> applies if the application itself holds a strong reference to the
> instance.
>
> This proposal would allow a well-designed program that creates or updates
> a large transaction set of persistent instances to flush periodically and
> not run out of memory.
>
> If an application constructs a large number of instances and flushes
> them, the only artifact remaining in the cache would be the memory that
> the instance was new. That is, if the instance were subsequently queried
> or obtained by id, the instance would still be persistent-new although
> the instance retrieved might be a different Java instance from the
> instance created and flushed.
>
> We could still use the evict method to remove even the memory of the life
> cycle state of the instance. So if the persistent-new instance were
> flushed, it would still be persistent-new, but if it were then evicted,
> it would be subsequently retrieved as a hollow or persistent-
> nontransactional instance.
>
> Please comment.
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>