Thanks again. ... Is the CDI interceptor supportd in TomEE but not per spec? Maybe I not understand you correctly?
Same question on @TransactionAttribute. ..is SUPPORTS as a type in the spec or something only TomEE supports? Regards LF On Sep 30, 2014 10:43 AM, "Romain Manni-Bucau" <[email protected]> wrote: > 2014-09-30 8:12 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: > > Thanks for your answers Romain.... some follow ups (and really preciate > > you help me out): > > > > - Will any types of exceptions result in 1 retry? Checked or runtime? > > it respect ejb exception handling (application exception or not > etc...). same as any business method > > > - Is the retry semantics applied to any type of trigger (regardless of if > > its a singleAction, interval or calendar)? > > yes > > > - You say the retry count is 1 by default, where can I configure that? Or > > is all configuration vendor specific, such as poll interval, number of > > threads etc? > > vendor specific: EjbTimer.RetryAttempts in properties or the ejb > deployment (openejb-jar) > > > - Is there any way of not having the timeout method run in a transaction? > > When I read the spec it looks like I will always get a new transaction? > So > > my options for rollback is to throw an system or application exception > > (with rollback true) or call setRollbackOnly on EJBContext > > @TransactionAttribute(SUPPORTS) should work > > > - What is the lifecycle of the time instances? Are they usually pooled or > > recreated between each timeout? I guess @PostConstruct/@PreDestroy is > > called > > same as any business method (stateless = pool, singleton = single) > > > - I understand that I can create an EJB interceptor for a timeout method > > using @AroundTimeout, what about CDI interceptors? I read in the spec > that > > the timeout method is not considered a business method and therefor no > CDI > > interceptors are invoked. Correct? > > > > yes only @AroundTimeout are considered but CDI interceptors can have it as > well. > > > > > On Mon, Sep 29, 2014 at 11:51 PM, Romain Manni-Bucau < > [email protected]> > > wrote: > > > >> Oops, 1 retry by default sorry > >> > >> Le lundi 29 septembre 2014, Romain Manni-Bucau <[email protected]> > a > >> écrit : > >> > Hi > >> > > >> > Le lundi 29 septembre 2014, Lars-Fredrik Smedberg <[email protected]> > a > >> écrit : > >> >> Hi! > >> >> > >> >> I try to find more information on EJB Timers, Exception handling and > >> more, > >> >> I look mostly at automatically created timers (using @Schedule and > >> >> @Schedules). > >> >> > >> >> Some question I have is: > >> >> > >> >> - I asume that a new transaction will start when the timeout method > is > >> >> called? Correct? > >> > Yes > >> >> - I also understand that I could annotate the method with > >> >> @TransactionAttribute(REQUIRES or REQUIRES_NEW) but that will also > >> always > >> >> give me a new transaction, correct? > >> > Yes > >> >> - The calendarTimer I can create using the TimerService is the same > type > >> of > >> >> timer that I can create using the @Schedule annotation, correct? > >> > Yes > >> >> - Is an intervalTimer internally just an calendarTimer? If not can I > >> create > >> >> such a timer using @Schedule? I know i can use e.g. > @Schedule(minutes = > >> >> "*/5") etc... > >> > No but still a quartz trigger > >> >> - Can I automatically create a singleActionTimer automatically or is > >> such a > >> >> use case hard to grasp? > >> > No but in a postconstruct of a singleton with @startup > >> >> - When using automatically created timers how are the container > handling > >> >> exceptions? Will the container retry? If so how many times and at > what > >> >> interval? Or will it simple retry at the next timeout? > >> > Default is 0 retry IIRC > >> >> > >> >> Regards > >> >> Lars-Fredrik > >> >> > >> >> > >> >> -- > >> >> Med vänlig hälsning / Best regards > >> >> > >> >> Lars-Fredrik Smedberg > >> >> > >> >> STATEMENT OF CONFIDENTIALITY: > >> >> The information contained in this electronic message and any > >> >> attachments to this message are intended for the exclusive use of the > >> >> address(es) and may contain confidential or privileged information. > If > >> >> you are not the intended recipient, please notify Lars-Fredrik > Smedberg > >> >> immediately at [email protected], and destroy all copies of this > >> >> message and any attachments. > >> >> > >> > > >> > -- > >> > > >> > > >> > Romain Manni-Bucau > >> > Twitter: @rmannibucau > >> > Blog: http://rmannibucau.wordpress.com/ > >> > LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> > Github: https://github.com/rmannibucau > >> > > >> > > >> > >> -- > >> > >> > >> Romain Manni-Bucau > >> Twitter: @rmannibucau > >> Blog: http://rmannibucau.wordpress.com/ > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> Github: https://github.com/rmannibucau > >> > > > > > > > > -- > > Med vänlig hälsning / Best regards > > > > Lars-Fredrik Smedberg > > > > STATEMENT OF CONFIDENTIALITY: > > The information contained in this electronic message and any > > attachments to this message are intended for the exclusive use of the > > address(es) and may contain confidential or privileged information. If > > you are not the intended recipient, please notify Lars-Fredrik Smedberg > > immediately at [email protected], and destroy all copies of this > > message and any attachments. >
