[
https://issues.apache.org/jira/browse/UIMA-5763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444408#comment-16444408
]
Marshall Schor commented on UIMA-5763:
--------------------------------------
This all started when a user didn't realize, when using the uima-as
send-and-receive APIs, that they could not "release" the cas until that
operation asynchronously completed.
The original goal was to throw an exception when users accidentally did this.
* This goal was somewhat expanded when it was realized that any update by
"users" could conflict with the uima-as asynchronous update that would happen
when the "receive" part of the asynchronous send=and-receive happened.
So, the imagined impl is:
* uima-as sets the no-access mode bit, in it's ansynch. send-and-receive, and
* then when it receives the reply, it updates the cas and resets the bit.
* There would need to be perhaps a 2 bit indicator:
** the prohibit-access bit (set/not set), and
** another bit (privileged), where the setting of 'privileged' would be an
"internal" API in UIMA, and uima-as would set this when it needed to update.
* This two bit approach avoids a race condition which could occur otherwise.
I just kind of made up this approach, right now; better ones welcome
> UIMA: need a way to lock a CAS to prevent user from releasing it prematurely
> ----------------------------------------------------------------------------
>
> Key: UIMA-5763
> URL: https://issues.apache.org/jira/browse/UIMA-5763
> Project: UIMA
> Issue Type: New Feature
> Components: UIMA
> Reporter: Jerry Cwiklik
> Assignee: Marshall Schor
> Priority: Major
> Fix For: 3.0.1SDK, 2.10.3SDK
>
>
> UIMA-AS client supports an async style of sending CASes for processing to a
> remote service. When using sendCAS( CAS aCas), the code serializes CAS and
> dispatches it to the remote but keeps the CAS in a cache. When a reply comes,
> the cached CAS is used to deserialize a response. The contract is that the
> user code should not call CAS.release(). When a reply finally comes, the CAS
> is handed over to an application callback and upon return from the callback,
> the UIMA-AS releases the CAS.
> Problem: there is nothing to prevent user code to violate the contract. If
> CAS.release() is called while UIMA-AS client awaits reply (or during reply
> deserialization), bad things happen. In a specific use case, a NPE was thrown
> during deserialization and debugging was quite painful.
> Proposed solution: to protect integrity of a CAS need a way to lock/unlock
> it. Such facility can be added to CASImpl class. When a user code tries to
> call release() when a CAS is locked, the code should throw an exception
> (IllegalStateException or similar).
> WDYT?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
