From dev-return-8168-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Mon May 19 19:41:57 2008 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 87018 invoked from network); 19 May 2008 19:41:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 May 2008 19:41:57 -0000 Received: (qmail 58828 invoked by uid 500); 19 May 2008 19:41:58 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 58802 invoked by uid 500); 19 May 2008 19:41:58 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 58791 invoked by uid 99); 19 May 2008 19:41:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 May 2008 12:41:58 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of wisneskid@gmail.com designates 64.233.166.182 as permitted sender) Received: from [64.233.166.182] (HELO py-out-1112.google.com) (64.233.166.182) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 May 2008 19:41:12 +0000 Received: by py-out-1112.google.com with SMTP id a29so672866pyi.36 for ; Mon, 19 May 2008 12:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=TInBwv/7OJCL0lHkUjgfXwUiZRjP/MDuZXwoiuQ0NBc=; b=X3V2CiyOiTL8bc0mQutq/GVUrPgqLNj5bYCuUaQH7iW8+v2AfX3RBR2pLZ9p2gcBFbAsy8Ax6utI5UTyYno2pxy6P5vQpxf/J3Tv4vQmyF/83/rclPg8+v7Wuy5CZLxXSm5mx95w9vBrre0vn72EE0vmmd1hNMUuMA4aQlp8xbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=hyTHP/7/MMRmup5gAQyJ7EDA9ZHkyJoTdG7H7ZeUpVLuw03O1ZDz+RdnN3Qco41oiWz/d2QEepJ19yaRV2eHDHGqmT6b+6RWMZsmjRQ0yQie23hxU+l1kMAs8UQS7+k1D9PMkzctk0+9HTK+wM6M8ubBHOd57D24B9oTqGbpios= Received: by 10.140.133.9 with SMTP id g9mr3885675rvd.235.1211226085823; Mon, 19 May 2008 12:41:25 -0700 (PDT) Received: by 10.141.146.20 with HTTP; Mon, 19 May 2008 12:41:25 -0700 (PDT) Message-ID: <864cafc0805191241o2a6d1df2jb3086aa6e40f90b0@mail.gmail.com> Date: Mon, 19 May 2008 12:41:25 -0700 From: "David Wisneski" To: dev@openjpa.apache.org Subject: datacache MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org I'd be interested in folks opinion on the following. Currently in section 10.1 of the OpenJPA doc on DataCache is the statement "OpenJPA's data cache is designed to provide significant performance increases over cacheless operation, while guaranteeing that behavior will be identical in both cache-enabled and cacheless operation." In various tests we have found this statement is not quite correct on various corner cases. And I would propose the following clarification "Behavior will be the same in both cache-enables and cachless operations except for the following cases: " 1. If inverse relationships are not set or set to inconsistent values, the inconsistent values will be stored in the DataCache and restored upon entity reactivation. Using the property openjpa.InverseManager=true can eliminate this type of problem. This differs from the situation where there is no DataCache, the inverse relationships are not stored in the database but are rather rebuild upon request. 2. Using a @PrimaryKeyJoinColumn on a unidirectional one-to-one relationship and not setting the relationship value to be consistent with the primary key value. The inconsistent values will be stored in the DataCache and restored upon entity activity. 3. Updating a field annotated with insertable=false and/or updateable=false. Updates to these fields will be stored in the DataCache and restored upon entity reactivation. This differs from the situation where there is no DataCache, the field values are not stored and upon reactivation the values are reset. 4. Mapping two or more fields to the same table column and setting the fields to different values. The DataCache treats the fields as independent values and the two values will be stored and later restored. This differs from the situation where there is no DataCache only one value is stored and upon reactivation both values will be consistent. 5. Changing a field from lazy to eager in a fetch plan will not have any affect if the DataCache is used to retrieve data upon entity reactivation and the field's state in the DataCache entry was not retrieved. 6. The EntityManager method refresh will not retrieve the current committed data from the database, rather it will retrieve the current data from the DataCache. If applications have updated the database bypassing the DataCache (which could happen using a nativeQuery update, a JPA QL bulk update or a legacy application update) a refresh will not cause the changed data in the database to be loaded. David Wisneski