Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 56042 invoked from network); 5 Dec 2005 17:53:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Dec 2005 17:53:10 -0000 Received: (qmail 12114 invoked by uid 500); 5 Dec 2005 17:53:10 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 12090 invoked by uid 99); 5 Dec 2005 17:53:10 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Dec 2005 09:53:10 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [192.18.98.36] (HELO brmea-mail-4.sun.com) (192.18.98.36) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Dec 2005 09:53:09 -0800 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jB5HqmD7002468 for ; Mon, 5 Dec 2005 10:52:48 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IR100D01CZEGU00@mail-amer.sun.com> (original mail from Craig.Russell@Sun.COM) for jdo-dev@db.apache.org; Mon, 05 Dec 2005 10:52:48 -0700 (MST) Received: from [129.145.133.145] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IR10041FDNZXB80@mail-amer.sun.com>; Mon, 05 Dec 2005 10:52:48 -0700 (MST) Date: Mon, 05 Dec 2005 09:52:46 -0800 From: Craig L Russell Subject: Re: TCK : DeleteCallback In-reply-to: <43945F60.1020706@spree.de> Sender: Craig.Russell@Sun.COM To: Michael Watzek Cc: jdo-dev@db.apache.org, JDO Expert Group Message-id: <2A228680-95D2-4493-9864-6FD85E4A83FA@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=Apple-Mail-65-879144198; micalg=sha1 References: <200512030954.28632.andy@jpox.org> <43945F60.1020706@spree.de> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --Apple-Mail-65-879144198 Content-Type: multipart/alternative; boundary=Apple-Mail-64-879143650 --Apple-Mail-64-879143650 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Dec 5, 2005, at 7:40 AM, Michael Watzek wrote: > Hi Craig, Andy > > I think there is a portability issue with this test case: > > The test case assumes that a JDO implementation supports managed > relationships, because it deletes instances which are referenced by > other instances. Due to the fact that it does not nullify those > references explicitely, the test will cause errors for JDO > implementations which do not support managed relationships. Given that the relationships are represented by foreign keys in the database for which the delete rule is specified as RESTRICT, this is true. > > In order to make the test case portable, it should explicitely > nullify references to the all deleted objects first. Afterwards, it > should call Query.deletePersistentAll. This seems to be a good solution. > > I think that the problem you discussed below will not show up after > this change because all updates would have been initiated > explicitely by the test case. The test case org/apache/jdo/tck/query/delete/DeleteCallback.java as checked in seems to ignore the preStore and postStore callbacks. public void preStore(InstanceLifecycleEvent event) { if (logger.isDebugEnabled()) { logger.debug("preStore event: " + JDOHelper.getObjectId(event.getSource())); } } public void postStore(InstanceLifecycleEvent event) { this.events.add(event); if (logger.isDebugEnabled()) { logger.debug("postStore event: " + JDOHelper.getObjectId(event.getSource())); } } } Another issue (minor) is the typo in the inner class name. Should be private class LifecycleVerifier. Regards, Craig > > What do you think? > > Regards, > Michael >> Hi Andy, >> On Dec 3, 2005, at 12:54 AM, Andy Jefferson wrote: >>> The DeleteCallback test when using relationships is apparently >>> insisting that no [pre/post]Store event is ever fired after the >>> first [pre/post]Delete event. I'd like to confirm why this is the >>> case. >>> JPOX does the following :- >>> >>> 1. Query.deletePersistentAll() called, so we flush all instances >>> passed in (this flushing is not in JPOX CVS as yet). >>> 2. [pre/post]Store are called on all flushed instances. >>> 3. deletePersistent is called on the first instance. This can >>> cause updates to related instances since the instance is now >>> deleted, >> I understand that deleting a referred instance makes the cache >> inconsistent with the datastore, but don't see anything in the >> specification that provides for the change to be reflected >> immediately via a flush. JDO doesn't disallow managing >> relationships. But flushing the changes is unexpected. >>> which can trigger a further [pre/post]Store on the related >>> instances (which aren't yet deleted, since their turn has not >>> come yet). >> Flushing behavior is described in 12.8 (explicit persistence >> manager flush()). Automatic flushing of instances to the datastore >> is not described anywhere. Flushing for evict, commit, and query >> is described. >>> >>> Where exactly does it say in the spec that a JDO implementation >>> cannot fire off further [pre/post]Store on related instances >>> during the deletion process ? i.e the JDO2 spec is expecting the >>> implementation to turn off reporting of events on all instances >>> in the process of being deleted ? >> No, it is expecting that flushing is done at specific times >> (evict, commit, query, and user-initiated) and not at other times. >> Craig >>> >>> >>> -- >>> Andy >> 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! > > > -- > ------------------------------------------------------------------- > Michael Watzek Tech@Spree Engineering GmbH > mailto:mwa.tech@spree.de Buelowstr. 66 > Tel.: ++49/30/235 520 36 10783 Berlin - Germany > Fax.: ++49/30/217 520 12 http://www.spree.de/ > ------------------------------------------------------------------- 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! --Apple-Mail-64-879143650 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

On Dec 5, = 2005, at 7:40 AM, Michael Watzek wrote:

Hi Craig, Andy

I think there is a portability = issue with this test case:

The test case assumes that a JDO = implementation supports managed relationships, because it deletes = instances which are referenced by other instances. Due to the fact that = it does not nullify those references explicitely, the test will cause = errors for JDO implementations which do not support managed = relationships.

Given that the relationships are = represented by foreign keys in the database for which the delete rule is = specified as RESTRICT, this is true.

In order = to make the test case portable, it should explicitely nullify references = to the all deleted objects first. Afterwards, it should call = Query.deletePersistentAll.

This seems to be a good = solution.

I think that the problem you = discussed below will not show up after this change because all updates = would have been initiated explicitely by the test = case.

The test case = org/apache/jdo/tck/query/delete/DeleteCallback.java=A0as checked in = seems to ignore the preStore and postStore callbacks.=A0

=A0 =A0 =A0=A0 =A0public = void preStore(InstanceLifecycleEvent event) {
=A0 =A0 =A0 =A0 = =A0 =A0 if (logger.isDebugEnabled()) {
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 logger.debug("preStore event: " +
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 = JDOHelper.getObjectId(event.getSource()));
=A0 =A0 =A0 =A0 =A0 = =A0 }=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0
=A0 =A0 =A0 =A0 = }=A0 =A0 =A0 =A0 =A0=A0
=A0 =A0 =A0=A0 =A0public void = postStore(InstanceLifecycleEvent event) {
=A0 =A0 =A0 =A0 =A0 = =A0 this.events.add(event);
=A0 =A0 =A0 =A0 =A0 =A0 if = (logger.isDebugEnabled()) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = logger.debug("postStore event: " +
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 = JDOHelper.getObjectId(event.getSource()));
=A0 =A0 =A0 =A0 =A0 = =A0 }=A0 =A0 =A0 =A0 =A0=A0
=A0 =A0 =A0 =A0 }=A0=A0 =
=A0 =A0 }=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0

Another issue (minor) is = the typo in the inner class name. Should be=A0private class = LifecycleVerifier.

Regards,

Craig


What do you think?

Michael
Hi Andy,
On Dec 3, 2005, at 12:54 AM, Andy Jefferson = wrote:
The = DeleteCallback test when using relationships is apparently insisting = that no [pre/post]Store event is ever fired after the first = [pre/post]Delete event. I'd like to confirm why this is the case.=A0
JPOX = does the following :-
1. Query.deletePersistentAll() = called, so we flush all instances passed in (this flushing is not in = JPOX CVS as yet).
2. [pre/post]Store are called on = all flushed instances.
3. deletePersistent is = called on the first instance. This can cause updates to related = instances since the instance is now deleted,
I understand that deleting a referred instance makes = the cache inconsistent with the datastore, but don't see anything in the = specification that provides for the change to be reflected immediately = via a flush. JDO doesn't disallow managing relationships. But flushing = the changes is unexpected.=A0
which can trigger a further = [pre/post]Store on the related instances (which aren't yet deleted, = since their turn has not come yet).
Flushing behavior is described in 12.8 (explicit = persistence manager flush()). Automatic flushing of instances to the = datastore is not described anywhere. Flushing for evict, commit, and = query is described.

Where = exactly does it say in the spec that a JDO implementation cannot fire = off further [pre/post]Store on related instances during the deletion = process ? i.e the JDO2 spec is expecting the implementation to turn off = reporting of events on all instances in the process of being deleted = ?
No, it is expecting that = flushing is done at specific times (evict, commit, query, and = user-initiated) and not at other times. Craig


--=A0
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!


--=A0
Michael Watzek=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tech@Spree Engineering = GmbH
mailto:mwa.tech@spree.de=A0 =A0 =A0 =A0 Buelowstr. = 66
Tel.:=A0 = ++49/30/235 520 36 =A0 =A0 = =A0 10783 Berlin - Germany
Fax.:=A0 ++49/30/217 520 12 =A0 =A0 =A0 http://www.spree.de/
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!


= --Apple-Mail-64-879143650-- --Apple-Mail-65-879144198 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHjCCAtcw ggJAoAMCAQICAw3FWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwMTEwMDA0MTA5WhcNMDYwMTEwMDA0MTA5WjBHMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSQwIgYJKoZIhvcNAQkBFhVDcmFpZy5SdXNzZWxsQFN1 bi5DT00wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDti7ZE4rO6oXKbLM02AG9WY55t udmBVL53fb3V3X5S1kvcJOk1NEMIYT/T7Ww+/hE955zvHT29+mIoNe8AW/yj1WUH8uGG2HxhwCHI UQTHmN/ioVJgjwUaYbtNMKbL/NRpnL0QWewdMJS+6IFzFyX7ADFW5cJ+UWNLvNeWAQtN0mtLildn vdOgh50i8YPvACNkCHoomGjXx0azcXbe1X3c5AgRI6e2CZe5k2lRFQFUMqkjdoMtQPoNqJ1BxH9l i4cnabl8mcTwHHl44hrvb8ThqwRf2pfJh2vVuwmgK6z4IWjOk4RQM+0ODsRdq67mBdimJYmPMK1p RMBHzrUsfKxNAgMBAAGjMjAwMCAGA1UdEQQZMBeBFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIj86LzxCHedStDLMEeqHLy+UFG7zIRHfChSIV42 +MvXicydXEBh8v0Ry1V2d/lY4jS78G5yW5R9fKt1U5nlRBCOVzdhomvSolnNRIT71wPVVDrAIVlA YpXKxSmVBq7+4hV+3ZLHDeq3qZnNmiJR0sTEUD16xZX1RJs9dRYPCHoRMIIDPzCCAqigAwIBAgIB DTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29t MB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbL rzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZ cmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0 cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQD AgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0B AQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3h YWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1 TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNxVkwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMjA1MTc1MjQ3WjAjBgkqhkiG9w0BCQQxFgQU CDwVDM73IXlZDD3d8z5KnVPbZtQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw3FWTB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNxVkwDQYJKoZIhvcNAQEBBQAEggEA pZSE1+tV4Y26ms+SFmj5aRCLdgzCVu61m1m/Wvgt5/C/1jN4y0nASWEKmjHUWHDjt8Lci50rQKj2 Khu592CWSYdeZbDiAUtYlsr5yAKyF5vmZw11UDcbirMTxJWDXS/7Mh2O3n6I4DhNNkFflg2EzpiG ndJ6PD1ciq7jSASLQa+YPmYiXHm7Sz94e1wmVJJZsyucAf1+YaSHMGSOnn2cUhNAz+3r9jaiXW/y 2IWOIouEGKtxwN21tZB4CNJzbisSBz2hKIo0MjU6Th1Sdihr54ba2r1YiNaM2BwXvBDKY4ffANav MCRId+RBpkaU4GqK8RMbqNtheLfJmTkO+yo2cAAAAAAAAA== --Apple-Mail-65-879144198--