On Dec 13, 2012, at 1:17 PM, "Howard W. Smith, Jr." <smithh032...@gmail.com>
wrote:
> David,
>
> 1. definitely not using @Asynchronous; that was no good at all
>
> 2. Actually, it was 2 seconds on the Windows Server 2008 64-bit 16GB RAM...
> always
>
> 3. Always 5 to 10 minutes to process 1 or 2 emails on Windows Server 2003
> 32-bit 4GB RAM
Good info thanks.
> 4. As noted on the JIRA, I tried the TransactionAttribute NEVER and
> REQUIRES_NEW on @Stateless EJB that was all invoked via @Schedule, and same
> test results, which are.... The EJB timer rolls back the transaction, and
> every database operation that the EmailStatelessBean completed...prior to
> @Schedule rolling back the transaction.
Right, that suggestion was never implemented as it was intended. Changing the
TransactionAttribute alone will do nothing. What we need is to 1) prevent a
transaction from being started and 2) creating a new and smaller transaction
scope through a small code rework.
The ApplicationScoped check backfired because it has the effect of locking
tables for much longer. We want to process each "email" in an individual
transaction and move away from one big transaction. This is really the most
critical step to take, no other steps or workarounds matter at this phase of
the problem.
Let's try this:
- Go back to the very original 5-10 minutes 32-bit code
- Split EmailSessionBean into two beans
- EmailSessionBean
- will be marked @TransactionAttribute(NEVER)
- will no longer have an @PersistenceContext EntityManager reference
- AirportShuttleRequestProcessorBean
- will be marked @TransactionAttribute(REQUIRES_NEW)
- will have only one public method, `createOrderForAirportShuttle`
- will do all persistence processing
The EmailSessionBean will have an @EJB reference to the new
AirportShuttleRequestProcessorBean. Effectively, we're splitting the code that
does the contacting the of the email server from the code that contacts the
database and we're creating several much smaller transactions.
-David
