| Stale root transaction causes GMF application to stop processing operations [message #153560] |
Fri, 05 October 2007 01:16  |
Eclipse User |
|
|
|
Originally posted by: vhirsl.gmail.com
This is a multi-part message in MIME format.
--------------060105030500030401040705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I believe the following behavior is a bug.
I introduced an NPE in the GMF mindmap example by applying the affixed
patch. The NPE is exercised when creating a dependency relationship
between two items.
The situation is best explained if we look at the code of
DiagramEditingDomain.postommit method lines 212 to 220:
InternalTransaction newTx = startTransaction(false, options);
-> deb.resourceSetChanged(
new ResourceSetChangeEvent(
this,
tx,
filtered));
newTx.commit();
The NPE is thrown in the line marked with -> causing newTx (tx is 464,
new Tx is 467 in the trace) never to commit. From that moment on, all
new transactions will have this transaction as parent (and root
transaction) and they will never postcommit and therefore there will be
no more ResourceSetChangeEvent-s generated.
As a consequence all further changes to the diagram or to the model will
fail. The user will have to restart the application.
Please try out this scenario and if you think it is valid, I'll be happy
to raise a bug.
Thanks,
Vmir
--------------060105030500030401040705
Content-Type: text/plain;
name="mindmap.diagram_patch.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="mindmap.diagram_patch.txt"
### Eclipse Workspace Patch 1.0
#P org.eclipse.gmf.examples.mindmap.diagram
Index: src/org/eclipse/gmf/examples/mindmap/diagram/edit/parts/Rela tionship3EditPart.java
============================================================ =======
RCS file: /cvsroot/modeling/org.eclipse.gmf/examples/org.eclipse.gmf.e xamples.mindmap.diagram/src/org/eclipse/gmf/examples/mindmap /diagram/edit/parts/Relationship3EditPart.java,v
retrieving revision 1.11
diff -u -r1.11 Relationship3EditPart.java
--- src/org/eclipse/gmf/examples/mindmap/diagram/edit/parts/Rela tionship3EditPart.java 11 Jun 2007 17:44:07 -0000 1.11
+++ src/org/eclipse/gmf/examples/mindmap/diagram/edit/parts/Rela tionship3EditPart.java 5 Oct 2007 04:54:14 -0000
@@ -58,7 +58,8 @@
* @generated
*/
protected Connection createConnectionFigure() {
-
+ Connection c = null;
+ c.getParent();
return new DashedLineOpenArrow();
}
--------------060105030500030401040705
Content-Type: text/plain;
name="mindmap transaction trace.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="mindmap transaction trace.txt"
>>> Activating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::464 at 1191558946562 ms
*** Started org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::464 read-only=false owner=main depth=1 options={block_cd_prop=true} at 1191558946562 ms
*** Committing org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::464 at 1191558946562 ms
>>> Precommitting org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::464 at 1191558946562 ms
>>> Activating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::465 at 1191558946562 ms
*** Started org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::465 read-only=true owner=main depth=2 options={} at 1191558946562 ms
*** Committing org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::465 at 1191558946562 ms
>>> Deactivating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::465 at 1191558946562 ms
*** Closed org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::465 at 1191558946562 ms
>>> Activating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::466 at 1191558946562 ms
*** Started org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::466 read-only=true owner=main depth=2 options={} at 1191558946562 ms
*** Committing org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::466 at 1191558946562 ms
>>> Deactivating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::466 at 1191558946562 ms
*** Closed org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::466 at 1191558946562 ms
*** Validating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::464 at 1191558946562 ms
>>> Deactivating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::464 at 1191558946562 ms
>>> Activating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::467 at 1191558946562 ms
*** Started org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::467 read-only=false owner=main depth=1 options={no_undo=false, block_cd_prop=true} at 1191558946562 ms
>>> Activating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::468 at 1191558946562 ms
*** Started org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::468 read-only=true owner=main depth=2 options={no_undo=false} at 1191558946562 ms
*** Committing org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::468 at 1191558946578 ms
>>> Deactivating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::468 at 1191558946578 ms
*** Closed org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::468 at 1191558946578 ms
>>> Activating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::469 at 1191560977609 ms
*** Started org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::469 read-only=true owner=main depth=2 options={no_undo=false} at 1191560977609 ms
*** Committing org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::469 at 1191560977609 ms
>>> Deactivating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::469 at 1191560977609 ms
*** Closed org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::469 at 1191560977609 ms
>>> Activating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::470 at 1191560977609 ms
*** Started org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::470 read-only=true owner=main depth=2 options={no_undo=false} at 1191560977609 ms
*** Committing org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::470 at 1191560977609 ms
>>> Deactivating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::470 at 1191560977609 ms
*** Closed org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::470 at 1191560977609 ms
>>> Activating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::471 at 1191560977609 ms
*** Started org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::471 read-only=true owner=main depth=2 options={no_undo=false} at 1191560977609 ms
*** Committing org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::471 at 1191560977609 ms
>>> Deactivating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::471 at 1191560977609 ms
*** Closed org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::471 at 1191560977609 ms
>>> Activating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::472 at 1191560977609 ms
*** Started org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::472 read-only=true owner=main depth=2 options={no_undo=false} at 1191560977609 ms
*** Committing org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::472 at 1191560977609 ms
>>> Deactivating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::472 at 1191560977609 ms
*** Closed org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::472 at 1191560977609 ms
>>> Activating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::473 at 1191560977609 ms
*** Started org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::473 read-only=true owner=main depth=2 options={no_undo=false} at 1191560977609 ms
*** Committing org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::473 at 1191560977609 ms
>>> Deactivating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::473 at 1191560977609 ms
*** Closed org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::473 at 1191560977609 ms
>>> Activating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::474 at 1191560977609 ms
*** Started org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::474 read-only=true owner=main depth=2 options={no_undo=false} at 1191560977609 ms
*** Committing org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::474 at 1191560977609 ms
>>> Deactivating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::474 at 1191560977609 ms
*** Closed org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::474 at 1191560977609 ms
>>> Activating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::475 at 1191560977625 ms
*** Started org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::475 read-only=true owner=main depth=2 options={no_undo=false} at 1191560977625 ms
*** Committing org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::475 at 1191560977625 ms
>>> Deactivating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::475 at 1191560977625 ms
*** Closed org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::475 at 1191560977625 ms
>>> Activating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::476 at 1191560977625 ms
*** Started org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::476 read-only=true owner=main depth=2 options={no_undo=false} at 1191560977625 ms
*** Committing org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::476 at 1191560977625 ms
>>> Deactivating org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::476 at 1191560977625 ms
*** Closed org.eclipse.gmf.examples.mindmap.diagram.EditingDomain::476 at 1191560977625 ms
--------------060105030500030401040705--
|
|
|
| Re: Stale root transaction causes GMF application to stop processing operations [message #154397 is a reply to message #153560] |
Tue, 09 October 2007 10:33  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Vmir,
It looks like some try/finally protection is missing. Run-time exceptions
generally are programming errors, but in a highly extensible system such as
the GMF run-time, it is worth bullet-proofing such critical resources as
transactions. Whether the correct thing to do on run-time exceptions is to
roll back the transaction or just commit it anyway is an interesting
question (would rollback really be able to recover?), but this looks like
something that should be addressed.
Cheers,
Christian
Vmir wrote:
> I believe the following behavior is a bug.
>
> I introduced an NPE in the GMF mindmap example by applying the affixed
> patch. The NPE is exercised when creating a dependency relationship
> between two items.
>
> The situation is best explained if we look at the code of
> DiagramEditingDomain.postommit method lines 212 to 220:
>
> InternalTransaction newTx = startTransaction(false, options);
> -> deb.resourceSetChanged(
> new ResourceSetChangeEvent(
> this,
> tx,
> filtered));
>
> newTx.commit();
>
> The NPE is thrown in the line marked with -> causing newTx (tx is 464,
> new Tx is 467 in the trace) never to commit. From that moment on, all
> new transactions will have this transaction as parent (and root
> transaction) and they will never postcommit and therefore there will be
> no more ResourceSetChangeEvent-s generated.
>
> As a consequence all further changes to the diagram or to the model will
> fail. The user will have to restart the application.
>
> Please try out this scenario and if you think it is valid, I'll be happy
> to raise a bug.
>
> Thanks,
> Vmir
|
|
|
| Re: Stale root transaction causes GMF application to stop processing operations [message #154744 is a reply to message #154397] |
Wed, 10 October 2007 19:29 |
| Eclipse User |
|
|
|
Originally posted by: vladimirh.edgewater.ca
Hi Christian,
and thanks for replying.
From my limited knowledge of Transactions framework I would assume that
it is better to rollback the transaction if the nested transaction has
not completed.
On the other hand, looking at the base class implementation, the
transaction will be successfully closed even if there are exceptions
thrown during its postcommit.
I think it is important that every transaction is eventually closed,
successfully or rolled back, rather than being left to pollute the
transaction stack.
I will raise a bug and I am sure you will come up with the right
solution ;-)
Cheers,
Vmir
Christian W. Damus wrote:
> Hi, Vmir,
>
> It looks like some try/finally protection is missing. Run-time exceptions
> generally are programming errors, but in a highly extensible system such as
> the GMF run-time, it is worth bullet-proofing such critical resources as
> transactions. Whether the correct thing to do on run-time exceptions is to
> roll back the transaction or just commit it anyway is an interesting
> question (would rollback really be able to recover?), but this looks like
> something that should be addressed.
>
> Cheers,
>
> Christian
>
>
> Vmir wrote:
>
>
>> I believe the following behavior is a bug.
>>
>> I introduced an NPE in the GMF mindmap example by applying the affixed
>> patch. The NPE is exercised when creating a dependency relationship
>> between two items.
>>
>> The situation is best explained if we look at the code of
>> DiagramEditingDomain.postommit method lines 212 to 220:
>>
>> InternalTransaction newTx = startTransaction(false, options);
>> -> deb.resourceSetChanged(
>> new ResourceSetChangeEvent(
>> this,
>> tx,
>> filtered));
>>
>> newTx.commit();
>>
>> The NPE is thrown in the line marked with -> causing newTx (tx is 464,
>> new Tx is 467 in the trace) never to commit. From that moment on, all
>> new transactions will have this transaction as parent (and root
>> transaction) and they will never postcommit and therefore there will be
>> no more ResourceSetChangeEvent-s generated.
>>
>> As a consequence all further changes to the diagram or to the model will
>> fail. The user will have to restart the application.
>>
>> Please try out this scenario and if you think it is valid, I'll be happy
>> to raise a bug.
>>
>> Thanks,
>> Vmir
>>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.24506 seconds
Home