Cache invalidation

Hello JDO developers, in our system we have several VMs that operate on the same database via JDO. We're performing distributed cache invalidation via our own notification mechanism, which effectively calls PMF.getDatastoreCache().evict() and PM.evict(). The problem here is that either evict(

Re: Cache invalidation

Hi Wes, thanks for your answer, please see my comments below. Wesley Biggs schrieb: Joerg von Frantzius wrote: The problem here is that either evict() accepts only PC objects, not object ids, so we have to call PM.getObjectById() beforehand. If no object for that id was present, we&#x

Re: Cache invalidation

ense to me is #1 above, and that seems debatable to me. Do most people using P-NT objects expect them to be consistent with the L2 cache at all times? Or are they expected to act like a limited form of an optimistic transaction? I don't have a strong opinion about this, I'm just trying to

Re: Issue 158: Specification clarification 11.3

Hi Craig, please see my comments below. Craig L Russell schrieb: Javadogs, While reviewing the spec in some more detail prior to closing it for the release, I noticed that there is a corollary to the requirement that "after close(), all methods that actually do anything must throw exceptio

Re: Issue 158: Specification clarification 11.3

naged, and that's entirely different from what the original PMF.getPersistenceManager() delivers. Regards, Jörg Craig L Russell schrieb: Hi Joerg, On Feb 10, 2006, at 3:42 PM, Joerg von Frantzius wrote: Hi Craig, please see my comments below. Craig L Russell schrieb: Javadogs, Whil

Re: Issue 158: Specification clarification 11.3

ded speculation? Craig On Feb 11, 2006, at 9:26 AM, Joerg von Frantzius wrote: Hello Craig, the problem is with code that manages PersistenceManagers and transaction demarcation itself, i.e. code without session beans, that is run inside an application server (I can give an example

Re: makePersistent detached instance deleted on database

Craig L Russell schrieb: Hi Erik, When you invoke makePersistent on a detached instance, the instance must exist in the database. You don't insert it at commit.[..] Does that mean that makePersistent() must not insert detached instances for which it cannot find an object in the datastore? I

Re: [DISCUSS} Server TimeZone

Hello Erik, this seems to be connected to thread Transaction Manager and JCA , where it seems you proposed to associate a single PersistenceManagerFactory with multiple DBs. As a PMF only has properties to connect and authenticate with

Re: [DISCUSS} Server TimeZone

tiple database connections per PMF without extending the spec? Quoting Joerg von Frantzius <[EMAIL PROTECTED]>: Hello Erik, this seems to be connected to thread Transaction Manager and JCA <http://www.jpox.org/servlet/forum/viewthread?thread=4099>, where it seems you proposed to a

Re: [DISCUSS} Server TimeZone

to?) How do you want to configure multiple database connections per PMF without extending the spec? Quoting Joerg von Frantzius <[EMAIL PROTECTED]>: Hello Erik, this seems to be connected to thread Transaction Manager and JCA <http://www.jpox.org/servlet/forum/viewthre

Re: Congratulations to Andy Jefferson

That's great! Cheers, Jörg Craig L Russell schrieb: > I'm happy to announce that Andy Jefferson has been voted by the DB PMC > to be given commit privileges on the Apache JDO project. > > This acknowledges the continuing contributions and commitment to > excellence that Andy has demonstrated. > >

Re: fetch group question

A workaround could be to define a fetch group for every single field in the .jdo file, and then assembling the desired combination at runtime (I remember somebody having done that before). Karan Malhi schrieb: > Sorry, > > The code should read as: > Query query = pm.newQuery(Person.class); > Fetch

Re: JDO 2.1 specification draft can be reviewed...

Wow! Is that really the site I used to know as apache's jdo site?! Andy Jefferson schrieb: > On 19 October 2007, David Ezzio (ys) wrote: > >> http://db.apache.org/jdo/documentation.html >> > > http://db.apache.org/jdo/specifications.html > >

Re: JDO 2.1 specification draft can be reviewed...

the site). Regards, Jörg Craig L Russell schrieb: > Hi Joerg, > > Andy Jefferson has put in a ton of work to upgrade the site. > > Craig > > On Oct 19, 2007, at 7:38 AM, Joerg von Frantzius wrote: > >> Wow! Is that really the site I used to know as apache's jdo

Re: multiple databases one PM/TX

Hi Erik, there is one thing that I don't understand about this proposed feature (which may be just me not seeing the obvious point of course :) Running 2PC on multiple data sources is handled already by J2EE implementations, and, as far as I recall, there are also libraries available that provide

Re: multiple databases one PM/TX

is pluggable > and enabled to accept any jta implementation. > > If you don't provide an external jta implementation, JPOX will use its > internal implementation. > -- BlackBerry® from Mobistar --- > > -Original Message- > From: Joerg von Frantzius <[EMAI

Re: [VOTE] Release Apache JDO 2.1

It was Red Hat who bought JBoss, and so Hibernate. Maybe for some reason Sun wants the RI rather to come from Oracle than from Red Hat? Uhm, or where did the JPA RI come from so far? David Jordan schrieb: +1 on the release... I was not happy to see the following bad news... http://www.informa

Re: [VOTE] Release Apache JDO 2.1

oh yeah, now Oracle. Harumph. Joerg von Frantzius wrote: It was Red Hat who bought JBoss, and so Hibernate. Maybe for some reason Sun wants the RI rather to come from Oracle than from Red Hat? Uhm, or where did the JPA RI come from so far? David Jordan schrieb: +1 on the release.

Re: JDO 2.2 feature list

Since we have setMaxFetchDepth() on FetchPlan, it would be good to also have a setRecursionDepth() on FetchPlan, maybe in addition to having the annotation on field level. At least I have a use-case here where that would be desirable. Craig L Russell schrieb: Hi, Now that JDO 2.1 has shipped

Re: JDO 2.2 feature list

oss an unloaded field during display. Not sure about the implications for implementations. If this feature is agreed to be interesting I'll try to come up with something here. This of course won't work with detached objects being serialized to a different VM. Joerg von Frantzi

TCK failures

Hi, I'm running runtck.jdori on current SVN trunk of jdo and datanucleus, and I'm getting the following error: derby-app-pmf-junit.txt: ** Tests run: 056, Time: 013 seconds. Failures: 0, Errors: 5 RUN Persistence.testGetPMFfromNamedPU ERROR RUN Persistence.testGetPMFfromN

Re: TCK failures

OK I was missing a clean on tck2, now all is well again :) (Hadn't wanted to wipe out the schema once more...) Sorry for bothering, Jörg Joerg von Frantzius schrieb: Hi, I'm running runtck.jdori on current SVN trunk of jdo and datanucleus, and I'm getting the following error:

Bidirectional relationship tests in the TCK

Hi, when looking at the relationship tests in org.apache.jdo.tck.mapping, it seems that the tests for bidirectional integrity only test changing relationships from the "mapped-by" side of the relationship? That's my impression at least from looking at the method names e.g. in Relationship1ToM

Re: Bidirectional relationship tests in the TCK

L Russell schrieb: HI Jörg, On May 27, 2008, at 9:51 AM, Joerg von Frantzius wrote: Hi, when looking at the relationship tests in org.apache.jdo.tck.mapping, it seems that the tests for bidirectional integrity only test changing relationships from the "mapped-by" side of the rela

Re: Bidirectional relationship tests in the TCK

uld of course be desirable if behaviour was consistent both in attached and detached state. Regards, Jörg Craig L Russell schrieb: Hi Jörg, On Jun 6, 2008, at 10:30 AM, Joerg von Frantzius wrote: Sorry for not having had any time to look into this more thoroughly yet. I'll hopefully find it

Re: Bidirectional relationship tests in the TCK

Craig L Russell schrieb: Hi Jörg, On Jun 9, 2008, at 1:43 AM, Joerg von Frantzius wrote: Hello Craig, what I really meant was: when modifying state of bidirectional associations on detached objects, should those detached objects immediately reflect consistent bidirectional state in the VM

How to avoid PM.getObjectById() checking for correct class in datastore?

Hi, when calling PersistenceManager.getObjectById() with a SingleFieldIdentity, there seems to be no way of avoiding the following (if the implementation decides to do so): "It is an implementation decision whether to access the data store, if required to determine the exact class. This will

Re: How to avoid PM.getObjectById() checking for correct class in datastore?

ave to worry at all about them being exact or not, since the implementation itself creates the ids that it later on consumes in getObjectById(). Regards, Jörg Craig L Russell wrote: Hi Jörg, On Jul 22, 2008, at 8:13 AM, Joerg von Frantzius wrote: Hi, when calling PersistenceManager.getObje

Re: Bidirectional relationship tests in the TCK

ation (i.e. enhanced code and StateManager behaviour). Regards, Jörg Craig L Russell wrote: Hi Jörg, On Jun 10, 2008, at 5:30 AM, Joerg von Frantzius wrote: Craig L Russell schrieb: Hi Jörg, On Jun 9, 2008, at 1:43 AM, Joerg von Frantzius wrote: Hello Craig, what I really meant was:

Re: Updating datastore with transient instance

Hi, the use-case sounds very reasonable to me, e.g. when the implementation of a web-service sends out a serialized persistent object, receives back the object with changes, and now needs to apply the changes to the database. Since makePersistent() is handling attaching so far, this could be the

runtck.iut

Hi, when I try to execute "maven runtck.iut" with datanucleus snapshot jars in tck2/iut_jars, I get the following: [java] Caused by: org.datanucleus.exceptions.NucleusException: Plugin (Bundle) "org.datanucleus.store.rdbms" is already registered. Ensure you dont have multiple JAR versions of

Re: runtck.iut

Never mind, my maven1 build problem got solved by using maven 1.1 instead of 1.0.2... Concerning runtck.iut, it just seems that the implementation under test can be any implementation except for datanucleus (testing of which can of course still be done using runtck.jdori). Joerg von Frantzius

Re: Bidirectional relationship tests in the TCK

ToManyNoRelationships.java: public void > testReplaceFromMappedbySide() { > RelationshipNegative1To1Test.java:public void > testA2BbutNotB2AMappedBy() { > RelationshipNegative1To1Test.java:public void > testSetOtherSideToNullMappedBy() { > > Please let us know if an important

Re: JDO and Clouds

Wow! Congratulations! This is really great news for JDO. Andy Jefferson wrote: >> There is renewed interest (e.g. cloud computing) in persistence APIs >> that don't have a fully ACID compliant, fully featured SQL back end, >> and yet the data is not simply key-value blob storage. >> > >

Detecting inconsistencies of mapped-by declarations?

Hi, in the XML metadata, it is possible to have multiple FCO fields, e.g. B.a1 and B.a2, with identical mapped-by pointing to the same field of the same related class, e.g. A.b. In effect this would theoretically mean that the FK should be shared among different associations in the object model. I

Re: Detecting inconsistencies of mapped-by declarations?

Andy Jefferson wrote: >> Should the implementation throw an error in such situations, warning the >> user of the erroneous metadata? >> > > Shared FK relations are a perfectly valid thing to have IMHO > http://www.datanucleus.org/products/accessplatform_1_1/jdo/orm/one_to_many_collection.html#

Re: Detecting inconsistencies of mapped-by declarations?

Erik Bengtson wrote: >> in the XML metadata, it is possible to have multiple FCO fields, e.g. >> B.a1 and B.a2, with identical mapped-by pointing to the same field of >> the same related class, e.g. A.b. In effect this would theoretically >> mean that the FK should be shared among different associa

Re: Detecting inconsistencies of mapped-by declarations?

two AbstractMemberMetaData objects can be related only One-To-One by means of mapped-by. Regards, Jörg Craig L Russell wrote: > Hi Jörg, > > On May 7, 2009, at 9:36 AM, Joerg von Frantzius wrote: > >> Hi, >> >> in the XML metadata, it is possible to have multiple FCO

Re: Detecting inconsistencies of mapped-by declarations?

Erik Bengtson wrote: >> Why would you want to have two different fields for the same >> association? As far as I can see, it would always hold true that >> b.a1==b.a2. You could express that in OCL in your UML, but in most cases >> in the jdo metadata the above would be an error. You could still ha

Re: Detecting inconsistencies of mapped-by declarations?

Maybe we could rule out the use of mapped-by in this case? Joerg von Frantzius wrote: > Hi Craig, > > thanks for your answer. I still wonder a bit about implications of > mapped-by when combined with interfaces. > > Suppose we have class AImpl with a field "b" of type i

Re: Detecting inconsistencies of mapped-by declarations?

Andy Jefferson wrote: >> Needless to say that supporting this rare corner case would make the >> implementation much more complex, in particular with respect to >> bidirectional management. >> >> Maybe we could rule out the use of mapped-by in this case? >> > > -1 > > Just because you don't ha

Query objects and hashCode() + equals()

Hi, it would be nice if the spec would mandate that implementations of javax.jdo.Query do correctly implement hashCode() and equals(). Alternatively, Query.toString() could be required to return the single-string representation of the query, or some dedicated method was added to provide it. This

Re: Query objects and hashCode() + equals()

o fix it in datanucleus myself. When that has happened, it could still be worth putting in the spec? Regards, Jörg On 10/23/2009 06:57 PM, Craig L Russell wrote: > Hi Jörg, > > On Oct 16, 2009, at 9:50 AM, Joerg von Frantzius wrote: > >> Hi, >> >> it wou

Update timeout?

Hi, the other day we had the problem that a row lock got held indefinitely in a production database, probably because of the appserver not properly committing a connection. As a consequence, the HTTP-threads of the appserver got blocked one after the other, during execution of an UPDATE statement.

Re: Query objects and hashCode() + equals()

to build a cache key from a given Query object, because the Query interface does not provide any getters, e.g. for its filter etc. The only solution would be to separately remember the properties of the Query object when it is built. Regards, Jörg > > Regards, > > Craig >> >

Re: Query objects and hashCode() + equals()

Hi Andy, all I could find in the docs was http://www.datanucleus.org/extensions/query_cache.html which is about caching of "query compilations". Or do you mean that it could be used to store query results along with a cached QueryCompilation object? On 11/17/2009 06:19 PM, Andy Jefferson wrote: >

Re: query timeout in JDO

Hi, I somehow got the feeling that having a single property for both query and and update timeouts will create confusion, if I got Michael right here. Imagine somebody wants to set an update timeout, but doesn't want to constrain the duration of queries (or have a higher timeout for queries). Now

Re: query timeout in JDO

Hi Craig, I also find your proposal very good. This all makes more sense now. Regards, Jörg On 12/04/2009 12:41 AM, Craig L Russell wrote: > Hi Michael, > > Good summary. > > The original request for this feature was to allow queries that were > either stuck (possible deadlock) or running away (