Hi 1. true 2. @ConcurrencyManagement(BEAN -> lock free, @Lock(READ) reentrantLock.readLock().lock/unlock is called (performance wise difference is not that important in general) 3. it should. comparison is fair 4. @TransactionAttribute defines the transactional context you want, required will create or inherit running tx, required_new will always creates a new one. CDI beans are "support" (ie I don't care)
Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-09-01 10:32 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: > Hi > > I have some questions on EJBs and concurrency, I hope someone can shed some > light on the following questions: > > 1. I have understood that the annotations @ConcurrencyManagement and @Lock > only are applicable to Singelton EJBs and that the default values are > container managed concurrency and WRITE lock, correct? > 2. What is the difference between annotating with > @ConcurrencyManagement(BEAN) vs using container managed concurrency and > annotating @Lock(READ) ? Is there better performance wise to use BEAN > managed concurrency if thread safety is no issue? > 3. Will an EJB annotate @ConcurrencyManagement(BEAN) simply ignore any > @Lock annotations? Is this the EJB equivalent to an @ApplicationScoped CDI > bean when it comes to concurrency? > 4. Is this a totally separate function from using tx and annotation > @TransactionAttribute ? I mean in the case of concurrent access to business > method in a bean that e.g. has @TransactionAttribute(REQUIRED) I will start > multiple transactions? > > Thanks > > 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.
