On Dec 13, 2012, at 2:01 PM, "Howard W. Smith, Jr." <smithh032...@gmail.com> wrote:
> Thanks for the response. Guess what... the 2 beans along with the names and > all... is exactly what I did 'yesterday', the only thing I did 'not' do was > mark each of the beans according to what you mentioned. Right, the annotations are a critical part. Splitting the code and not changing the TransactionAttribute annotations as noted would essentially still result in one big transaction (i.e. no change). Educational point; when no @TransactionAttribute is specified on an EJB, it defaults to @TransactionAttribute(REQUIRED) REQUIRED basically means "join the existing transaction if possible, otherwise create one". So EmailSessionBean would create a transaction in the @Schedule method and every method invocation on AirportShuttleRequestProcessorBean would just join the existing transaction. The result: - one big transaction that locks all tables and doesn't let them go till getEmails completes - if email 1 from Joe fails, all email processing will fail and rollback when getEmail completes So aside from a performance problem, there's a very real business logic problem. Splitting them *and* adjusting the transaction settings will fix the business problem and likely help with the performance problem. The big difference of 2 seconds on 64-bit vs several minutes on a 32-bit is alarming and very likely a system issue of some kind. That said, going down this path of shrinking transaction scope will help zero in on where the problem occurs. -David
