Re: ApacheCon Europe
I'll be there as well. Craig On Apr 25, 2007, at 12:05 AM, Patrick Linskey wrote: Hey, Is anyone else going to be at ApacheCon next week? Marc Prud'hommeaux and I will both be there. -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: More questions on runtime schema generation
On Apr 26, 2007, at 1:49 PM, David Jencks wrote: Thanks for all the comments, I've learned a lot. 1. I have a classloader scanning strategy written and apparently working, however it is rather slow at least in geronimo. Is anyone interested in it, seeing as how its not an appropriate approach in a app server according to Patrick's comment below? I think it might still be useful as a "last resort" strategy. 2. It looks like the best strategy for geronimo to follow is to figure out which jars in an ee app can possibly have persistent classes in them and supply a list of those jars to the PersistenceUnitInfo. IIUC scanning those jars is already implemented. IIRC the spec limited the scope of a persistence unit to the jar that contains the persistence.xml file, so we shouldn't have to do deep scanning. 3. I can't get running ddl on a connection from an XADataSource in a simulated "RequiresNew" transaction to work reliably with derby. The ddl appears to work fine but attempts to read data from the created sequence table hang until the tx times out and derby does not report any deadlocks. Based on Craig's comments I've added a non-jta-datasource and this seems to be working much better. Has anyone seen problems like this? (seems unlikely in this context since i had to modify a bunch of stuff to get to this problem :-) If the outer transaction has previously read from that table, you have created a self deadlock. Have you checked the sql to make sure that there isn't a query that referenced the sequence table? -dain
RE: More questions on runtime schema generation
> > 2. It looks like the best strategy for geronimo to follow > is to figure > > out which jars in an ee app can possibly have persistent classes in > > them and supply a list of those jars to the > PersistenceUnitInfo. IIUC > > scanning those jars is already implemented. > > IIRC the spec limited the scope of a persistence unit to the > jar that contains the persistence.xml file, so we shouldn't > have to do deep scanning. ... but the developer can list additional jars in locations relative to the deployed jar, and the container is responsible for providing resolvable URLs for those jars via PUInfo. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Dain Sundstrom [mailto:[EMAIL PROTECTED] > Sent: Friday, April 27, 2007 9:22 AM > To: open-jpa-dev@incubator.apache.org > Subject: Re: More questions on runtime schema generation > > On Apr 26, 2007, at 1:49 PM, David Jencks wrote: > > > Thanks for all the comments, I've learned a lot. > > > > 1. I have a classloader scanning strategy written and apparently > > working, however it is rather slow at least in geronimo. Is anyone > > interested in it, seeing as how its not an appropriate > approach in a > > app server according to Patrick's comment below? I think it might > > still be useful as a "last resort" strategy. > > > > 2. It looks like the best strategy for geronimo to follow > is to figure > > out which jars in an ee app can possibly have persistent classes in > > them and supply a list of those jars to the > PersistenceUnitInfo. IIUC > > scanning those jars is already implemented. > > IIRC the spec limited the scope of a persistence unit to the > jar that contains the persistence.xml file, so we shouldn't > have to do deep scanning. > > > 3. I can't get running ddl on a connection from an XADataSource in > > a simulated "RequiresNew" transaction to work reliably with > derby. > > The ddl appears to work fine but attempts to read data from the > > created sequence table hang until the tx times out and > derby does not > > report any deadlocks. Based on Craig's comments I've added a > > non-jta-datasource and this seems to be working much better. Has > > anyone seen problems like this? (seems unlikely in this > context since > > i had to modify a bunch of stuff to get to this problem :-) > > If the outer transaction has previously read from that table, > you have created a self deadlock. Have you checked the sql > to make sure that there isn't a query that referenced the > sequence table? > > -dain > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Merge Detached Entity Problem
Hi All, I'm running into a problem developing a web application that utilizes JSF and JPA. Not sure if my problem is related to an OpenJPA bug, or a flaw in my approach. I'm hoping you can help. In my web application, a user selects an item to "edit" from a table of all available items. They are then directed to a page containing a form which allows them to modify the details of the item they selected (pretty standard web app stuff). Upon submission, the backing bean connected to this form invokes the update method of the item's data access object. The DAO in turn creates and EntityManager from the EntityManagerFactory, starts a transaction, merges the detached object, and commits the transaction. If any value is modified on the item edit form, the detached object is merged and successfully committed. That's good. Now for the problem: If the detached object is NOT modifed (edit form submitted w/o any changes) the merge will fail on the EntityManager transaction commit with the following error: <2|true|0.9.5-incubating> org.apache.openjpa.persistence.RollbackException: Optimistic locking errors were detected when flushing to the data store. The following objects may have been concurrently modified in another transaction: [com.coincident.green.beans.User-com.coincident.green.beans.User-1] I've read through the lifecycle management documentation and don't see why attempting to merge an unchanged detached entity would result in an exception. I could probably detect that no updates were made at my JSF managed bean and avoid the merge operation altogether, but what happens when my item references other managed entities and I want to utilize cascade merge? Hoping you all might have some thoughts. Here are a few details about my environment: Sun JDK 1.5.0_06 Apache Tomcat 5.5.20 MyFaces 1.1.3 OpenJPA 0.9.5 (Packaged w/BEA Workship Studio and Kodo) MySQL 5.0.27 (Community) Thanks! Please let me know if you require any more information. Regards, -jmh Jason M. Hanna President/Founder Coincident, Inc.
Re: Merge Detached Entity Problem
An update - I was not using the @Version annotation in my item definition. After updating my class with the annotation and adding additional database column, my original reported problem disappears. My first read of the documentation led me to believe the @Version annotation was a best practice, but not necessary. From the OpenJPA User's Guide, Section 1.4: ---start Note OpenJPA fully supports version fields, but does not require them for concurrency detection. OpenJPA can maintain surrogate version values or use state comparisons to detect concurrent modifications. See Section 7, " Additional JPA Mappings " in the Reference Guide. ---end I seem to have resolved my immediate issue, but perhaps someone can set me straight on the expected behavior when the @Version annotation is not present. Thanks, -jmh On 4/27/07, Jason Hanna <[EMAIL PROTECTED]> wrote: Hi All, I'm running into a problem developing a web application that utilizes JSF and JPA. Not sure if my problem is related to an OpenJPA bug, or a flaw in my approach. I'm hoping you can help. In my web application, a user selects an item to "edit" from a table of all available items. They are then directed to a page containing a form which allows them to modify the details of the item they selected (pretty standard web app stuff). Upon submission, the backing bean connected to this form invokes the update method of the item's data access object. The DAO in turn creates and EntityManager from the EntityManagerFactory, starts a transaction, merges the detached object, and commits the transaction. If any value is modified on the item edit form, the detached object is merged and successfully committed. That's good. Now for the problem: If the detached object is NOT modifed (edit form submitted w/o any changes) the merge will fail on the EntityManager transaction commit with the following error: <2|true|0.9.5-incubating> org.apache.openjpa.persistence.RollbackException: Optimistic locking errors were detected when flushing to the data store. The following objects may have been concurrently modified in another transaction: [com.coincident.green.beans.User-com.coincident.green.beans.User-1] I've read through the lifecycle management documentation and don't see why attempting to merge an unchanged detached entity would result in an exception. I could probably detect that no updates were made at my JSF managed bean and avoid the merge operation altogether, but what happens when my item references other managed entities and I want to utilize cascade merge? Hoping you all might have some thoughts. Here are a few details about my environment: Sun JDK 1.5.0_06 Apache Tomcat 5.5.20 MyFaces 1.1.3 OpenJPA 0.9.5 (Packaged w/BEA Workship Studio and Kodo) MySQL 5.0.27 (Community) Thanks! Please let me know if you require any more information. Regards, -jmh Jason M. Hanna President/Founder Coincident, Inc.
RE: [DISCUSS] OpenJPA Graduation
In terms of graduation, if we go the top-level route, I'd like to propose Craig as the PMC chair. I think that he'd be a good fit since he's quite active in the OpenJPA community, and also has a good deal of knowledge about and experience within Apache. I think that he would do a great job of continuing to represent Apache-isms to the OpenJPA community and vice-versa. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, April 23, 2007 2:50 PM > To: open-jpa-dev@incubator.apache.org > Subject: [DISCUSS] OpenJPA Graduation > > OpenJPA has done a great job of forming a diverse community > around a great code base whose IP has been reviewed and > approved for release, and we're now a well-functioning, > project in the incubator. So we are now at the stage when we > should think about when and how to leave the incubator and > graduate to the larger Apache community. The document at [1] > describes readiness to graduate. > > There are two courses for graduating projects: to become an > independent Apache TLP or to join an existing TLP as a > sub-project. I believe that OpenJPA should become its own TLP > for a few reasons: the community is already very diverse and > has established a good working style; and there is no > existing TLP upon which OpenJPA depends. There is some > synergy with the DB project but no dependency relationship. > > As a TLP, OpenJPA would operate independent from other TLPs > and be responsible to the Apache board. As a TLP, the OpenJPA > community would decide on offering committerships to the > project, and what and when to release, subject to the > regulations of the ASF. > > So what does everyone think? > > Craig > > [1] http://incubator.apache.org/incubation/ > Process_Description.html#Graduation > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: [DISCUSS] OpenJPA Graduation
Patrick, On 4/27/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: In terms of graduation, if we go the top-level route, I'd like to propose Craig as the PMC chair. I second that "vote", if you are not interested. Craig has gotten us out of "Apache hot water" a few times with his background on Apache-isms. And, he has demonstrated his overall technical knowledge in JPA and persistence issues, in general. I would think Craig would make an excellent PMC chair. Kevin I think that he'd be a good fit since he's quite active in the OpenJPA community, and also has a good deal of knowledge about and experience within Apache. I think that he would do a great job of continuing to represent Apache-isms to the OpenJPA community and vice-versa. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, April 23, 2007 2:50 PM > To: open-jpa-dev@incubator.apache.org > Subject: [DISCUSS] OpenJPA Graduation > > OpenJPA has done a great job of forming a diverse community > around a great code base whose IP has been reviewed and > approved for release, and we're now a well-functioning, > project in the incubator. So we are now at the stage when we > should think about when and how to leave the incubator and > graduate to the larger Apache community. The document at [1] > describes readiness to graduate. > > There are two courses for graduating projects: to become an > independent Apache TLP or to join an existing TLP as a > sub-project. I believe that OpenJPA should become its own TLP > for a few reasons: the community is already very diverse and > has established a good working style; and there is no > existing TLP upon which OpenJPA depends. There is some > synergy with the DB project but no dependency relationship. > > As a TLP, OpenJPA would operate independent from other TLPs > and be responsible to the Apache board. As a TLP, the OpenJPA > community would decide on offering committerships to the > project, and what and when to release, subject to the > regulations of the ASF. > > So what does everyone think? > > Craig > > [1] http://incubator.apache.org/incubation/ > Process_Description.html#Graduation > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: SVN revision needed when checking in openjpa.jar
(Moving a conversation about svn version data in the release to open-jpa-dev) To elaborate further, right now, I think that we use command-line extraction of this data via some rather ugly mvn. We certainly should be able to get the branch data (or at least the full URL to the root directory). The full URL probably doesn't belong in the version string, but probably does belong in the output of 'java org.apache.openjpa.conf.OpenJPAVersion'. I imagine that we could get better / more concise data if we used JavaSVN or did some scripting or something. Ideally, I'd love it if after graduation, our version IDs looked like this: Leading up to the hypothetical 1.3.2 release: - If from a branch, openjpa-1.3.2-SNAPSHOT-- - If from trunk, openjpa-1.3.2-SNAPSHOT- - If from a release branch, openjpa-1.3.2 java org.apache.openjpa.conf.OpenJPAVersion would always include the full URL to the base directory, and the corresponding svn number. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: David Ezzio [mailto:[EMAIL PROTECTED] > Sent: Friday, April 27, 2007 1:13 PM > To: Patrick Linskey > Cc: Marc Prud'hommeaux; /USER wls-ejb-dev > Subject: Re: SVN revision needed when checking in openjpa.jar > > Hi Patrick, > > I'm not sure about that first number. My visual SVN client > (SmartSVN) does not show any revisions associated with > directories. I suspect that SVN is like P4 where directories > are artifacts of files and have no independent life of their > own. Do you see a revision number associated with directories? > > In any case, it would be much clearer if the branch name was > inserted into the version info. Can that be done? > > David > > Patrick Linskey wrote: > > The first number is the last revision of the top-level > directory itself. > > We don't change the top-level directory all that much, so > this info is > > mostly useless. > > > > The second number (after the colon) is the last revision > number of the > > svn repository as a whole (i.e., across all of > svn.apache.org, IIRC). > > > > If you see an 'M' after the second number, it means that there are > > local changes. Release builds should not have this M there, ever. > > > > So, IOW, I don't think that we include branching info, although I > > guess it can be inferred from the first number, since the top-level > > dir will be different in a branch. So, from that data, we probably > > have an approximation of the branch, and we know the > globally-unique > > latest svn revision number from when the build happened. > > > > -Patrick > > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: [DISCUSS] OpenJPA Graduation
> I second that "vote", if you are not interested. Just FTR, it's not so much that I'm not interested as much as I think that I have much to learn in the ways of Apache before I'd be the best PMC chair for our project. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Kevin Sutter [mailto:[EMAIL PROTECTED] > Sent: Friday, April 27, 2007 1:23 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: [DISCUSS] OpenJPA Graduation > > Patrick, > > On 4/27/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: > > > > In terms of graduation, if we go the top-level route, I'd like to > > propose Craig as the PMC chair. > > > I second that "vote", if you are not interested. Craig has > gotten us out of "Apache hot water" a few times with his > background on Apache-isms. And, he has demonstrated his > overall technical knowledge in JPA and persistence issues, in > general. I would think Craig would make an excellent PMC chair. > > Kevin > > I think that he'd be a good fit since > > he's quite active in the OpenJPA community, and also has a > good deal > > of knowledge about and experience within Apache. I think > that he would > > do a great job of continuing to represent Apache-isms to > the OpenJPA > > community and vice-versa. > > > > -Patrick > > > > -- > > Patrick Linskey > > BEA Systems, Inc. > > > __ > > _ > > Notice: This email message, together with any attachments, may > > contain information of BEA Systems, Inc., its > subsidiaries and > > affiliated entities, that may be confidential, proprietary, > > copyrighted and/or legally privileged, and is intended > solely for the > > use of the individual or entity named in this message. If > you are not > > the intended recipient, and have received this message in error, > > please immediately return this by email and then delete it. > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Sent: Monday, April 23, 2007 2:50 PM > > > To: open-jpa-dev@incubator.apache.org > > > Subject: [DISCUSS] OpenJPA Graduation > > > > > > OpenJPA has done a great job of forming a diverse > community around a > > > great code base whose IP has been reviewed and approved > for release, > > > and we're now a well-functioning, project in the incubator. So we > > > are now at the stage when we should think about when and how to > > > leave the incubator and graduate to the larger Apache > community. The > > > document at [1] describes readiness to graduate. > > > > > > There are two courses for graduating projects: to become an > > > independent Apache TLP or to join an existing TLP as a > sub-project. > > > I believe that OpenJPA should become its own TLP for a > few reasons: > > > the community is already very diverse and has established a good > > > working style; and there is no existing TLP upon which OpenJPA > > > depends. There is some synergy with the DB project but no > dependency > > > relationship. > > > > > > As a TLP, OpenJPA would operate independent from other > TLPs and be > > > responsible to the Apache board. As a TLP, the OpenJPA community > > > would decide on offering committerships to the project, > and what and > > > when to release, subject to the regulations of the ASF. > > > > > > So what does everyone think? > > > > > > Craig > > > > > > [1] http://incubator.apache.org/incubation/ > > > Process_Description.html#Graduation > > > > > > Craig Russell > > > Architect, Sun Java Enterprise System > > > http://java.sun.com/products/jdo > > > 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good > JDO? O, Gasp! > > > > > > > > > > Notice: This email message, together with any attachments, may > > contain information of BEA Systems, Inc., its > subsidiaries and > > affiliated entities, that may be confidential, proprietary, > > copyrighted and/or legally privileged, and is intended > solely for the > > use of the individual or entity named in this message. If > you are not > > the intended recipient, and have received this message in error, > > please immediately return this by email and then delete it. > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted
FW: [VOTE] [RESULT] approve release of OpenJPA 0.9.7
Congratulations, all! Thanks, Michael, for making this happen. It's great to know that we've now gone through a release driven by a non-BEA member of the community. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Michael Dick [mailto:[EMAIL PROTECTED] > Sent: Friday, April 27, 2007 1:21 PM > To: [EMAIL PROTECTED] > Subject: Re: [VOTE] [RESULT] approve release of OpenJPA 0.9.7 > > Vote results : > > Binding : > Niclas Hedhman +1 > James Strachan +1 > Craig Russell + 1 > Eddie O'Neil +1 > > Non Binding : > Dain Sunstrom +1 > Patrick Linksey +1 > Kevin Sutter +1 > > The vote passes with 4 IPMC +1 votes. > > I will prepare an announcement notice. > > Thank you for your support. > > -Michael Dick > On 4/27/07, Eddie O'Neil <[EMAIL PROTECTED]> wrote: > > > > +1 (binding) > > > > Also, I'm all for requesting that incubating projects requesting > > IPMC approval of a release provide a RAT report as well as > > explanations for any missing license headers since that's a > focus of a > > lot of the ensuing conversation about a release. > > > > Eddie > > > > > > On 4/26/07, Michael Dick <[EMAIL PROTECTED]> wrote: > > > On 4/26/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > > > > > > > > Also, it's probably worth pointing out that > schemas-doctype.rsrc > > > > > is OpenJPA IP, and not a redistribution of someone else's IP. > > > > > > > > Ah, OK. Hadn't seen this before I posted. > > > > > > > > --- Noel > > > > > > > > > In future releases I'll remember to clarify that > > > schemas-doctype.rsrc is OpenJPA's IP. I should have been > more clear > > > in the original email, now > > that > > > I read it again I can see how it would cause confusion. > > > > > > -- > > > -Michael Dick > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Resolved: (OPENJPA-226) Change openjpa.DetachState 'fgs' setting to 'fetch-groups'
[ https://issues.apache.org/jira/browse/OPENJPA-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey resolved OPENJPA-226. - Resolution: Fixed > Change openjpa.DetachState 'fgs' setting to 'fetch-groups' > -- > > Key: OPENJPA-226 > URL: https://issues.apache.org/jira/browse/OPENJPA-226 > Project: OpenJPA > Issue Type: Improvement > Components: docs, kernel >Affects Versions: 0.9.0, 0.9.6, 0.9.7 >Reporter: Patrick Linskey > Assigned To: Patrick Linskey >Priority: Minor > Fix For: 0.9.8 > > Attachments: OPENJPA-226.patch > > > The configuration setting "openjpa.DetachState: fgs" is a bit obtuse. It > would be nicer if this were "openjpa.DetachState: fetch-groups". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-230) Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider
Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider --- Key: OPENJPA-230 URL: https://issues.apache.org/jira/browse/OPENJPA-230 Project: OpenJPA Issue Type: Bug Components: kernel Affects Versions: 0.9.6, 0.9.0, 0.9.7 Reporter: Vikram Bhatia Priority: Minor When an application is commiting a transaction and then terminating, often not all events regarding Data Cache are dispatched by the TCPRemoteCommitProvider. It seems that the JVM on termination is not waiting until TCPRemoteCommitProvider has dispatched all events regarding Data Cache. In this way some cache synchronization is lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-230) Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider
[ https://issues.apache.org/jira/browse/OPENJPA-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikram Bhatia updated OPENJPA-230: -- Attachment: soln.diff Proposed Solution. > Handle guaranteed delivery of Data Cache events on normal JVM termination > using TCPRemoteCommitProvider > --- > > Key: OPENJPA-230 > URL: https://issues.apache.org/jira/browse/OPENJPA-230 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.0, 0.9.6, 0.9.7 >Reporter: Vikram Bhatia >Priority: Minor > Attachments: soln.diff > > > When an application is commiting a transaction and then terminating, often > not all events regarding Data Cache are dispatched by the > TCPRemoteCommitProvider. It seems that the JVM on termination is not waiting > until TCPRemoteCommitProvider has dispatched all events regarding Data Cache. > In this way some cache synchronization is lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-230) Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider
[ https://issues.apache.org/jira/browse/OPENJPA-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey updated OPENJPA-230: Attachment: OPENJPA-230.patch It'd be nice to not have to synchronize. What about if we made the threads non-daemon, and just call setRunning(false) instead? See attached (completely-untested) patch. Also, I think that that boolean should be volatile to ensure thread-safety. > Handle guaranteed delivery of Data Cache events on normal JVM termination > using TCPRemoteCommitProvider > --- > > Key: OPENJPA-230 > URL: https://issues.apache.org/jira/browse/OPENJPA-230 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.0, 0.9.6, 0.9.7 >Reporter: Vikram Bhatia >Priority: Minor > Attachments: OPENJPA-230.patch, soln.diff > > > When an application is commiting a transaction and then terminating, often > not all events regarding Data Cache are dispatched by the > TCPRemoteCommitProvider. It seems that the JVM on termination is not waiting > until TCPRemoteCommitProvider has dispatched all events regarding Data Cache. > In this way some cache synchronization is lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-230) Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider
[ https://issues.apache.org/jira/browse/OPENJPA-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492398 ] Vikram Bhatia commented on OPENJPA-230: --- Well I have though about it, but it fails the following scenario. 1. Four Threads running and eight Packets in queue. The four threads are busy sending packets. 3. In case, _keepRunning is set to false, four packets will still be left to synchronize as threads exit from while loop. > Handle guaranteed delivery of Data Cache events on normal JVM termination > using TCPRemoteCommitProvider > --- > > Key: OPENJPA-230 > URL: https://issues.apache.org/jira/browse/OPENJPA-230 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.0, 0.9.6, 0.9.7 >Reporter: Vikram Bhatia >Priority: Minor > Attachments: OPENJPA-230.patch, soln.diff > > > When an application is commiting a transaction and then terminating, often > not all events regarding Data Cache are dispatched by the > TCPRemoteCommitProvider. It seems that the JVM on termination is not waiting > until TCPRemoteCommitProvider has dispatched all events regarding Data Cache. > In this way some cache synchronization is lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-230) Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider
[ https://issues.apache.org/jira/browse/OPENJPA-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikram Bhatia updated OPENJPA-230: -- Attachment: reproducer.zip > Handle guaranteed delivery of Data Cache events on normal JVM termination > using TCPRemoteCommitProvider > --- > > Key: OPENJPA-230 > URL: https://issues.apache.org/jira/browse/OPENJPA-230 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.0, 0.9.6, 0.9.7 >Reporter: Vikram Bhatia >Priority: Minor > Attachments: OPENJPA-230.patch, reproducer.zip, soln.diff > > > When an application is commiting a transaction and then terminating, often > not all events regarding Data Cache are dispatched by the > TCPRemoteCommitProvider. It seems that the JVM on termination is not waiting > until TCPRemoteCommitProvider has dispatched all events regarding Data Cache. > In this way some cache synchronization is lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-230) Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider
[ https://issues.apache.org/jira/browse/OPENJPA-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey updated OPENJPA-230: Attachment: OPENJPA-230.patch Good point -- _keepRunning is a bit too abrupt. How does this work? > Handle guaranteed delivery of Data Cache events on normal JVM termination > using TCPRemoteCommitProvider > --- > > Key: OPENJPA-230 > URL: https://issues.apache.org/jira/browse/OPENJPA-230 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.0, 0.9.6, 0.9.7 >Reporter: Vikram Bhatia >Priority: Minor > Attachments: OPENJPA-230.patch, OPENJPA-230.patch, reproducer.zip, > soln.diff > > > When an application is commiting a transaction and then terminating, often > not all events regarding Data Cache are dispatched by the > TCPRemoteCommitProvider. It seems that the JVM on termination is not waiting > until TCPRemoteCommitProvider has dispatched all events regarding Data Cache. > In this way some cache synchronization is lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] OpenJPA Graduation
FWIW, I third the "vote". On Apr 27, 2007, at 1:22 PM, Kevin Sutter wrote: Patrick, On 4/27/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: In terms of graduation, if we go the top-level route, I'd like to propose Craig as the PMC chair. I second that "vote", if you are not interested. Craig has gotten us out of "Apache hot water" a few times with his background on Apache-isms. And, he has demonstrated his overall technical knowledge in JPA and persistence issues, in general. I would think Craig would make an excellent PMC chair. Kevin I think that he'd be a good fit since he's quite active in the OpenJPA community, and also has a good deal of knowledge about and experience within Apache. I think that he would do a great job of continuing to represent Apache-isms to the OpenJPA community and vice-versa. -Patrick -- Patrick Linskey BEA Systems, Inc. _ __ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, April 23, 2007 2:50 PM > To: open-jpa-dev@incubator.apache.org > Subject: [DISCUSS] OpenJPA Graduation > > OpenJPA has done a great job of forming a diverse community > around a great code base whose IP has been reviewed and > approved for release, and we're now a well-functioning, > project in the incubator. So we are now at the stage when we > should think about when and how to leave the incubator and > graduate to the larger Apache community. The document at [1] > describes readiness to graduate. > > There are two courses for graduating projects: to become an > independent Apache TLP or to join an existing TLP as a > sub-project. I believe that OpenJPA should become its own TLP > for a few reasons: the community is already very diverse and > has established a good working style; and there is no > existing TLP upon which OpenJPA depends. There is some > synergy with the DB project but no dependency relationship. > > As a TLP, OpenJPA would operate independent from other TLPs > and be responsible to the Apache board. As a TLP, the OpenJPA > community would decide on offering committerships to the > project, and what and when to release, subject to the > regulations of the ASF. > > So what does everyone think? > > Craig > > [1] http://incubator.apache.org/incubation/ > Process_Description.html#Graduation > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/ products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Merge Detached Entity Problem
That is an odd manifestation of the problem. Definitely worth investigation. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Jason Hanna [mailto:[EMAIL PROTECTED] > Sent: Friday, April 27, 2007 11:55 AM > To: open-jpa-dev@incubator.apache.org > Subject: Re: Merge Detached Entity Problem > > An update - I was not using the @Version annotation in my > item definition. After updating my class with the annotation > and adding additional database column, my original reported > problem disappears. > > My first read of the documentation led me to believe the > @Version annotation was a best practice, but not necessary. > > From the OpenJPA User's Guide, Section 1.4: > > ---start > Note > > OpenJPA fully supports version fields, but does not require > them for concurrency detection. OpenJPA can maintain > surrogate version values or use state comparisons to detect > concurrent modifications. See Section 7, " Additional JPA > Mappings " in the Reference Guide. > > ---end > > I seem to have resolved my immediate issue, but perhaps > someone can set me straight on the expected behavior when the > @Version annotation is not present. > > Thanks, > -jmh > > > On 4/27/07, Jason Hanna <[EMAIL PROTECTED]> wrote: > > Hi All, > > > > I'm running into a problem developing a web application > that utilizes > > JSF and JPA. Not sure if my problem is related to an > OpenJPA bug, or a > > flaw in my approach. I'm hoping you can help. > > > > In my web application, a user selects an item to "edit" > from a table > > of all available items. They are then directed to a page > containing a > > form which allows them to modify the details of the item > they selected > > (pretty standard web app stuff). > > > > Upon submission, the backing bean connected to this form > invokes the > > update method of the item's data access object. The DAO in turn > > creates and EntityManager from the EntityManagerFactory, starts a > > transaction, merges the detached object, and commits the > transaction. > > > > If any value is modified on the item edit form, the > detached object is > > merged and successfully committed. That's good. Now for the problem: > > > > If the detached object is NOT modifed (edit form submitted w/o any > > changes) the merge will fail on the EntityManager > transaction commit > > with the following error: > > > > <2|true|0.9.5-incubating> > > org.apache.openjpa.persistence.RollbackException: > Optimistic locking > > errors were detected when flushing to the data store. The > following > > objects may have been concurrently modified in another transaction: > > [com.coincident.green.beans.User-com.coincident.green.beans.User-1] > > > > I've read through the lifecycle management documentation > and don't see > > why attempting to merge an unchanged detached entity would > result in > > an exception. > > > > I could probably detect that no updates were made at my JSF managed > > bean and avoid the merge operation altogether, but what > happens when > > my item references other managed entities and I want to utilize > > cascade merge? > > > > Hoping you all might have some thoughts. Here are a few > details about > > my environment: > > > > Sun JDK 1.5.0_06 > > Apache Tomcat 5.5.20 > > MyFaces 1.1.3 > > OpenJPA 0.9.5 (Packaged w/BEA Workship Studio and Kodo) > MySQL 5.0.27 > > (Community) > > > > Thanks! Please let me know if you require any more information. > > > > Regards, > > -jmh > > > > Jason M. Hanna > > President/Founder > > Coincident, Inc. > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-230) Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider
[ https://issues.apache.org/jira/browse/OPENJPA-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492413 ] Vikram Bhatia commented on OPENJPA-230: --- It works based on size of the packet queue. Once the broadcast queue is empty, it interrupts the thread assuming that all the packets are broadcasted. Why do _processLock is required? It may call interrupt even if the thread is calling sendUpdateQueue if we dont have a syncronization. I was thinking about having boolean variable, but that will have synchronization issues, and thread may be interrupted without completely sending the packet. > Handle guaranteed delivery of Data Cache events on normal JVM termination > using TCPRemoteCommitProvider > --- > > Key: OPENJPA-230 > URL: https://issues.apache.org/jira/browse/OPENJPA-230 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.0, 0.9.6, 0.9.7 >Reporter: Vikram Bhatia >Priority: Minor > Attachments: OPENJPA-230.patch, OPENJPA-230.patch, reproducer.zip, > soln.diff > > > When an application is commiting a transaction and then terminating, often > not all events regarding Data Cache are dispatched by the > TCPRemoteCommitProvider. It seems that the JVM on termination is not waiting > until TCPRemoteCommitProvider has dispatched all events regarding Data Cache. > In this way some cache synchronization is lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-230) Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider
[ https://issues.apache.org/jira/browse/OPENJPA-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492416 ] Vikram Bhatia commented on OPENJPA-230: --- I tried this too, but what will happen in case thread is already in wait() state, and there are no more packets. join() will keep on waiting forever and process will never exit. > Handle guaranteed delivery of Data Cache events on normal JVM termination > using TCPRemoteCommitProvider > --- > > Key: OPENJPA-230 > URL: https://issues.apache.org/jira/browse/OPENJPA-230 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.0, 0.9.6, 0.9.7 >Reporter: Vikram Bhatia >Priority: Minor > Attachments: OPENJPA-230.patch, OPENJPA-230.patch, reproducer.zip, > soln.diff > > > When an application is commiting a transaction and then terminating, often > not all events regarding Data Cache are dispatched by the > TCPRemoteCommitProvider. It seems that the JVM on termination is not waiting > until TCPRemoteCommitProvider has dispatched all events regarding Data Cache. > In this way some cache synchronization is lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
