2014-09-30 11:44 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: > Thanks again. ... > > Is the CDI interceptor supportd in TomEE but not per spec? Maybe I not > understand you correctly? >
That's @AroundTimeout so that's portable normally but not handled by CDI but EJB container, but since both are well integrated it is smooth > Same question on @TransactionAttribute. ..is SUPPORTS as a type in the spec > or something only TomEE supports? Spec AFAIK > > 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. >>
