Experts,
I had not received any feedback so far. If you think we should not add
async timeout capabilities, please say so. Otherwise please provide your
input.
Thank you,
-marina
Marina Vatkina wrote:
> Experts,
>
> This question was brought up some time ago, but got lost among other
> discussions. (Sorry about that). Let's resolve it.
>
> Please vote on the choices in each group below or provide your own
> solution proposal for further discussion.
>
> A. The definition:
>
> Async timeout will determine the time limit on:
>
> A1. Wait time before an async method begins execution;
> A2. Limit on the execution time of an async method;
> A3. A sum of A1 + A2;
>
> B. The timeout behavior:
>
> If the method execution did not complete (did not start in case of A1)
> when the timeout expires, the method execution will not abruptly stop,
> but:
> B1. The transaction, if active, will be marked for rollback;
> B2. SessionContext.wasCancelCalled(), when called within the context
> of that asynchronous method, will return true;
> B3. If the method returns a Future, the future will be marked as done,
> and the exception TBD will be available from Future.get() as the cause
> of java.util.concurrent.ExecutionException;
> B4. All of the above for A2 or A3 or B3 only in case of A1.
>
>
> C. Possible solutions:
>
> C1. Reuse AccessTimeout annotation. This doesn't seem a good match
> either in the name (there is no *access* timeout) or matching the
> current use cases with the new one.
> C2. Create a new annotation, e.g. AsynchronousTimeout
> C3. Add 2 new elements to the Asynchronous annotation value/unit (to
> match those in the AccessTimeout) with the defaults providing no-limit
> behavior (i.e. backward compatible with EJB 3.1).
>
> D. Exception name. (See item B3 on the exception handling part)
>
> D1. Add new AsynchronousTimeoutException
> D2. Reuse XYZ exception (I can't think of any)
> D3. Add new ABC exception
> D4. No exception necessary.
>
> thanks,
> -marina