From open-jpa-dev-return-3346-apmail-incubator-open-jpa-dev-archive=incubator.apache.org@incubator.apache.org Tue Apr 10 20:24:39 2007 Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 94268 invoked from network); 10 Apr 2007 20:24:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Apr 2007 20:24:38 -0000 Received: (qmail 90909 invoked by uid 500); 10 Apr 2007 20:24:45 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 90779 invoked by uid 500); 10 Apr 2007 20:24:44 -0000 Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: open-jpa-dev@incubator.apache.org Delivered-To: mailing list open-jpa-dev@incubator.apache.org Received: (qmail 90770 invoked by uid 99); 10 Apr 2007 20:24:44 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Apr 2007 13:24:44 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [192.18.42.249] (HELO nwk-ea-fw-1.sun.com) (192.18.42.249) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Apr 2007 13:24:37 -0700 Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3AKOE4v011346 for ; Tue, 10 Apr 2007 13:24:16 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGA00E01TUED700@d1-sfbay-09.sun.com> (original mail from Craig.Russell@Sun.COM) for open-jpa-dev@incubator.apache.org; Tue, 10 Apr 2007 13:24:14 -0700 (PDT) Received: from [192.168.0.13] (c-24-6-172-77.hsd1.ca.comcast.net [24.6.172.77]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGA008E4U0C5QC0@d1-sfbay-09.sun.com> for open-jpa-dev@incubator.apache.org; Tue, 10 Apr 2007 13:24:13 -0700 (PDT) Date: Tue, 10 Apr 2007 13:24:10 -0700 From: Craig L Russell Subject: Re: Can I reuse instances? In-reply-to: <467EAF1D-5335-4D34-8BF7-DE86C28DE205@iq80.com> Sender: Craig.Russell@Sun.COM To: open-jpa-dev@incubator.apache.org Message-id: <541611C4-9FAB-47B9-A57B-851994ECB70F@SUN.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=Apple-Mail-156-360955408; micalg=sha1 References: <77F77403-9FB9-4525-980C-01BE6C155836@iq80.com> <7D856CDFE035FF45A0420ACBD71BDD6303D1F68D@repbex02.amer.bea.com> <9DF0F4A4-3EBC-47BF-9609-C934904D29CF@iq80.com> <963203EF-D420-4A2B-A218-498384B5D85D@SUN.com> <467EAF1D-5335-4D34-8BF7-DE86C28DE205@iq80.com> X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-156-360955408 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Dain, On Apr 10, 2007, at 12:58 PM, Dain Sundstrom wrote: > On Apr 9, 2007, at 5:44 PM, Craig L Russell wrote: > >> Hi Dain, >> >> On Apr 9, 2007, at 11:10 AM, Dain Sundstrom wrote: >> >>> On Apr 8, 2007, at 1:56 PM, Craig L Russell wrote: >>> >>>> Hi Dain, >>>> >>>> I haven't looked in detail at the life cycle of CMP beans in a >>>> couple of years, but in general you can't simply keep the state >>>> of the underlying Entities through the life cycle. CMP beans are >>>> pooled and reused in transaction contexts and you have to load >>>> the state at specific points in the life cycle. >>> >>> It depends on the commit option the container is using. In >>> commit option A, you assume the cmp engine is the sole user of >>> the database, so you don't need to load. Normally people use >>> commit option B where you keep instances activated with a >>> specific primary key and reload the data in each tx. >>> >>>> Using the primary key stored in the CMP bean to do em.find at >>>> the appropriate time is the obvious way to take advantage of the >>>> em second level cache. To the extent that this is not efficient, >>>> we should fix it in the JPA layer not the CMP layer. >>> >>> I would prefer to keep as much of the CMP stuff on the CMP side >>> as possible so the JPA implementation can focus on JPA issues. >>> One of the assumption of JPA is that entities are light weight >>> and cheap to create, so you take the safe route and construct a >>> new one when every you need an instance. In CMP the assumption >>> is that entity instances are expensive to create, so less safe >>> route and you pool them. Reusing instances is really a CMP >>> problem, but I don't think it can be implemented without the help >>> of the JPA engine. >> >> I'm afraid we're getting wrapped around the axle on definitions. >> Here's what I'm trying to get across: >> >> CMP Entity Beans are expensive to create and there's a lot of >> required behavior to manage them. You pretty much have to >> implement the life cycle in the spec. It's your choice how to >> implement the "state" part of the beans. You can use wrappers >> around various kinds of state objects like ResultSet or generated >> classes that contain fields with the state. >> >> Your implementation uses JPA Entities to hold the state. These JPA >> Entities are not at all specified by CMP Entity Beans. JPA >> Entities as cheap to create so all you need to do is hold on to >> the ids and when you need state from the database, ask JPA >> EntityManager for the state. If the state is already in the second >> level cache, this is very cheap to access. > > In my implementation the CMP entity is the JPA entity. They are > the same object. There are no "state holders". Now I understand. I don't think the design works, from lots of different perspectives. > We choose this design to easy the transition from CMP to JPA but > has the drawback that we are completely reliant on the JPA > implementation for instance management. I don't think the design can work. The CMP protocol requires separating the CMP instance from its state. You are generating the CMP concrete implementation class as part of deployment, and the concrete class needs to contain state or a reference to state. My experience is that keeping state directly in the CMP bean isn't likely to work well. Sorry for the distracting comments. I didn't imagine that you were trying to directly persist CMP beans. Craig > > -dain 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-156-360955408 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw ggJyoAMCAQICECpJVMO68ii+Xfsc1O1YYFIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTIwOTE5NTEwNVoXDTA3MTIwOTE5NTEw NVowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNAB4Ih+ShsCt89HzqIdwEx8L4o1UHiY6V7 16mrCedfd4Y0/uI7z9Zam8ysgEh+F7aDnQEKmEsVFN35G4nPMfLU6dZYkvADwUjbq82t/dJ3FDDg Q945nHHpqECZff/S/UMho9AFfj6PZvZBAlDCJAayb4RdKIlfuvPW9YcQStQ1IfVJcVuKnC0Q+tdc a4A7zn7IzLOQohO1lTc3hXSBigEIGiGYn6Ny0wmexfA3X1WsXekFx5czd+M4GjDjswn8CNoBmnBr jOTGK1mOsXR6GSRHnly2s9xTdE4qv9qimM+7C2yzMHbKcszV7OQoLsRsZKDh+6u9wYU+TrjcY4ym bA8CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEFBQADgYEAU/EpPDztnb55Fz7iGSVm1mYEVj5m2OQKTYG26POUAomCBRrt /CdBBvqYmcHUTpra0qLELHAQadYFl2v11iQkqwF5PPJs19oU/zA0m5qFnOMTAiCvel7IprIwA2r6 eJR9siaPwDRgVJ/Sj71dD+utwf+nRrNy0/7PMNK5y+ocsYQwggM/MIICqKADAgECAgENMA0GCSqG SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+ hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECECpJVMO68ii+Xfsc1O1YYFIwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDEwMjAyNDExWjAjBgkqhkiG9w0B CQQxFgQUadPmKhalTspghrZAjho/RKRoUE4wgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqSVTDuvIovl37HNTtWGBSMIGHBgsqhkiG 9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAq SVTDuvIovl37HNTtWGBSMA0GCSqGSIb3DQEBAQUABIIBAFtl1udMQlyb/ZbrLS3eFax5mWQz/0jJ 0IKdA3i+f+BGI0Xugvk5EvxmcPhzCKj/m41kqAv/xx/TbOOd2I04Nv9Cyv2yaZV7+RBw77rVonQB +Szrl5onSsscHB7LAo5HntyDAbWRhdbcGSDE6cTVLgR8tmTWCObdDDHoeYWQ8OfYhkxvoNfjAQle nCKzDBcyk6szR28OmPLvW4a+IA/UGNY4Osksd6VTcJ6BRjeuNNxsK2X0Jymp4f1a6MJOY6qZpfrb MjlP8ide/V4AcZs7GKm5JjYi7aEed+lO6JgGQ9guBcVsD/0k/XD5977DlxC7RyJDJBSUnVihpR8D xuf2IQgAAAAAAAA= --Apple-Mail-156-360955408--