Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EMF's Lock class doesn't restore/propogate InterruptedExceptions #13

Open
pcdavid opened this issue Sep 4, 2022 · 1 comment
Open
Labels
bugzilla Issues migrated from the old Eclipse Bugzilla

Comments

@pcdavid
Copy link
Contributor

pcdavid commented Sep 4, 2022

  • πŸ†” Bugzilla ID: #308252
  • πŸ“˜ Project: Modeling / EMF Services / Transaction
  • πŸ—“ Created: 2010-04-06T18:13:26Z
  • ❓ Status: NEW /
@pcdavid pcdavid added the bugzilla Issues migrated from the old Eclipse Bugzilla label Sep 4, 2022
@pcdavid
Copy link
Contributor Author

pcdavid commented Sep 4, 2022

Comment #0 on Tue Apr 06 2010 20:13:26 GMT+0200 (Central European Summer Time):

Build Identifier: 

Proper handling of InterruptedExceptions is a must, but especially in classes designed to deal with Locks. 

The EMF lock class swallowed interrupts in some cases. This means that interrupting a thread performing an acquire might cause upstream code to fail to receive the expected interrupt. 


Reproducible: Always

Comment #1 on Tue Apr 06 2010 20:14:03 GMT+0200 (Central European Summer Time):



Comment #2 on Tue May 11 2010 16:35:27 GMT+0200 (Central European Summer Time):

So via Bug 306987 you are both proposing we apply the patch for Helios? Is this something that will be of any risk?

Comment #3 on Wed May 12 2010 17:47:05 GMT+0200 (Central European Summer Time):

I am not aware of any bugs this may help solve. Though this may make the lock class more concurrent, what effects will it have on existing applications? The given change may make the Lock class less aggressive.

For example, there is an addition of throwing an InterruptedException in the uiSafeAcquire method. What are the side effects of this when a transaction needs to begin and has already been interrupted? Existing applications may just log the exception and give up on the transaction.

I think we need to test EMFT applications intensively to see what other side effects this may have. The JUnits for EMFT are also pretty comprehensive.

Comment #4 on Wed May 12 2010 18:46:32 GMT+0200 (Central European Summer Time):

(In reply to comment #3)
> I am not aware of any bugs this may help solve. [snip]

So not for Helios then...

Comment #5 on Sat May 14 2022 15:51:52 GMT+0200 (Central European Summer Time):

Eclipse EMF Transaction is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/emf-transaction.

If this issue is relevant to you and still present in the latest release:

* Create a new issue at https://github.com/eclipse/emf-transaction/issues/.
  * Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience)
  * In the GitHub description, start with a link to this bugzilla ticket
  * Optionally add new content to the description if it can helps towards resolution
* Update bugzilla ticket
  * Add to "See also" property (up right column) the link to the newly created GitHub issue
  * Add a comment "Migrated to <link-to-newly-created-GitHub-issue>"
  * Set status as CLOSED MOVED

All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for EMF Transaction will be archived and made read-only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from the old Eclipse Bugzilla
Projects
None yet
Development

No branches or pull requests

1 participant