Funny, I just sent that suggestion :) But it took me too long to type it -- didn't see your response came in before I finished :)
-David On Dec 11, 2012, at 12:53 PM, "Howard W. Smith, Jr." <smithh032...@gmail.com> wrote: > I think I'm going to avoid the single transaction (via single @Stateless > EJB) approach, and use other @Stateless EJBs to make the database table > updates. This approach works everywhere else throughout the web app. > > I'll just keep the @Stateless EJB for the purpose of being invoked by > @Schedule, and it will be the 'driver', and call the > already-defined-and-already-used other @Stateless EJBs that contain > Persistent context and entity manager to update tables, so this clearly > will be a multiple transaction commit, which should 'not' lock any tables. > :) > > > > On Tue, Dec 11, 2012 at 3:21 PM, Howard W. Smith, Jr. < > smithh032...@gmail.com> wrote: > >> Prior to adding this @Stateless EJB (that's invoked via @Schedule every 10 >> minutes), my JSF web app has been running 100% okay without any deadlocks >> or anything else like that. >> >> So, is it okay if I just add optimistic locking, em.lock(entity, >> LockType.Optimistic) before any/all em.persist(...) that I have in the >> @Stateless EJB? >> >> JSF web app is working okay, because the JSF components call multiple >> @Stateless EJB that usually do any of the following, SELECT, UPDATE, >> DELETE, on one table at time. >> >> >> >> On Tue, Dec 11, 2012 at 2:35 PM, Howard W. Smith, Jr. < >> smithh032...@gmail.com> wrote: >> >>> You're absolutely right, David. Thanks for the response. >>> >>> It is a transaction issue and the @Stateless EJB is holding a transaction >>> open and writing into 6 to 10 tables in a single database, which is also >>> the database accessed by JSF components (by endusers). The @Stateless EJB >>> is on a timer ( @Schedule), checks email server for incoming requests from >>> customers, and takes that data and inserts it into database, so endusers >>> don't have to manually enter the data (that they receive from these >>> formmail results). >>> >>> Below is the exception that I saw maybe an hour or two ago, and I >>> confirmed that it's a locking/transaction issue, and from the stacktrace, >>> it seems as though the JSF components cannot access the table, that is >>> evidently locked by @Stateless EJB. The @Stateless @EJB updated all tables >>> on my faster/dev/test server on average of 1 to 2 seconds, and/so in my >>> opinion, the data is not that much at all, maybe a few kbytes of data being >>> inserted into the database. Anyway, I've been reading up on pessismistic >>> and optimistic locking, and that's where I was in my reading before I >>> noticed your email. I really don't know what the database or JPA is >>> defaulting to, because honestly, I have no code that specifies any locks. >>> Recently, I only added query hint (readonly) to JPA queries. Personally, I >>> feel as though I can use 'no locking' for these inserts, since this is >>> brand new data, but the JSF components may be locking the entites/tables >>> during simple queries (SELECT statements). Feel free to change this >>> email/topic to a more suitable topic/subject, if necessary. :) >>> >>> >>> >>>
