What about two message queues instead of the Singleton? One to process
creation of entities, maybe even serialized, and the other as a callback
to let the rest of your system to know an entity has been created?
Also, for this kind of transactional behavior, you wouldn't want to look
only at the concept of "flat" transaction-- I think your problem is best
solved with a "transactional saga". A transactional saga involves a
series of isolated transactions; for each transaction there is a
"reverse transaction" that undos previous, commited TXs.
T1 s ----->T2 s ----->T3 s---> EndOfTXSaga
f f
| |
R1 ----+----R2----+
(s) means success, (f) means failure.
R1 undoes T1, R2 undoes T2.
Transactional Sagas are commonly used whenever steps inside transactions
are (one or more of the following):
1) Require high degree of isolation.(Are used in conjunction with
message queues or singletons).
2) Require long processing times(a quick hack is to raise the deadlock
watchdog timeout, but the remedy is worse than the disease).
3) Require user interaction _in the middle_ of the transaction.
4) Require abritrary/difficult to predict waiting/processing times in
between steps.
My 2c,
Juan Pablo Lorandi
Chief Software Architect
Code Foundry Ltd.
[EMAIL PROTECTED]
Barberstown, Straffan, Co. Kildare, Ireland.
Tel: +353-1-6012050 Fax: +353-1-6012051
Mobile: +353-86-2157900
www.codefoundry.com
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]] On Behalf Of Richard S.Martin
> Sent: Wednesday, July 17, 2002 7:53 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Entity creation locking problem
>
>
> Another aspect to the problem (I should have mentioned it in
> my original
> post) is that we have an EIS (a customer care and billing
> system) sitting between us and the db. For particularly
> dubious reasons, we cannot write to the database directly,
> but have to use the EIS's bespoke API (I have written a
> resource adapter to handle this).
>
> It is within the guts of this single "create entity" API call
> that the 5 seconds or so are elapsing.
>
> We *do* have some control over the structure of the
> underlying table: When I added a unique constraint on the
> primary key field I suddenly found that the system could only
> handle one concurrent user! (It seemed obvious in
> retrospect)
>
> Somebody suggested I use a Singleton which maintains a list
> of primary keys currently being created. The first thing the
> create process would then do is check to see if the id exists
> in the list. If not, it would add it to the list and the
> perform the creation processing, remove it from the list and
> commit the transaction. If it finds the id is already on the
> list, it throws an exception.
>
> My problem with this solution is twofold:
>
> First, the Singlton would have to be replaced with some
> enterprise suitable object backed by a shared database. This
> not only seems like an over complication of the system, but
> also has a performance impact. (Although you could argue that
> with an existing transaction time of 5 seconds, the few extra
> milliseconds of reaching out to the db a couple of times is
> negligable)
>
> Secondly, the system the looses the theoretical notion of a
> transaction. More specifically, the isolation principle is
> lost since a second transaction's success is dependant upon
> the existence of the incomplete first transaction. Now my
> management may argue that they couldn't care a fig for the
> isolation principle, and if I cannot find find a better
> solution this is what I will be forced to implement.
>
> There *must* be a better solution.
>
>
> On Wednesday 17 July 2002 15:38 pm, you wrote:
> > Richard,
> >
> > The INSERT will acquire a (table) lock depending on the transaction
> > isolation level you specify for the datasource used by your EJBs.
> >
> > So, the possible solutions are:
> > (a) Lower the isolation level (if your application can get away with
> > it), Or
> > (b) Specify that the ejbCreate() needs to run in its own transaction
> > (RequiresNew). Therefore, locks will be now be held for
> a smaller
> > duration of time. But you are now breaking up your long running
> > transaction into smaller ones; and this might not be acceptable.
> > (c) Explore the use of lock timeouts (can be set as properties in
> > some JDBC drivers).
> > (d) Explore the use of CMP - here the Container has a lot
> more control
> > over when SQLs are sent to the database and might be option iff
> > your EJB Container has the ability to defer writes
> (INSERTs, etc)
> > to the database.
> >
> > -krish
> >
> > > -----Original Message-----
> > > From: A mailing list for Java(tm) 2 Platform, Enterprise Edition
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Richard S.Martin
> > > Sent: Wednesday, July 17, 2002 6:14 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Entity creation locking problem
> > >
> > >
> > > Problem:
> > >
> > > 1. The uniqueness of the entity beans is based upon an unique
> > > constraint on the primary key field in the underyling database.
> > >
> > > 2. The ejbCreate method on the BMP entity bean, due to various
> > > essential business processes, takes a long time to write
> the data to
> > > the table. (in the region of 5-10 secs.)
> > >
> > > 3. As soon as the INSERT statement occurs, the
> transaction acquires
> > > a table-lock to ensure the uniquness of the primary key.
> > >
> > > 4. The lock is only released when the transaction commits or
> > > rollsback.
> > >
> > > 5. The consequence of this is that every ejbCreate causes
> the table
> > > to be exclusively locked for about 5 seconds, meaning we
> can handle
> > > only a single ejbCreate at any time!
> > >
> > > How can this problem be resolved?
> > >
> > >
> > >
> > >
> >
> >=============================================================
> ============
> > >===== This email and any files transmitted with it are
> confidential and
> > > intended solely for the use of the individual or entity
> to whom they are
> > > addressed. All information is the view of the individual and not
> > > necessarily the company. If you are not the intended
> recipient you are
> > > hereby notified that any dissemination, distribution, or
> copying of this
> > > communication and its attachments is strictly prohibited.
> If you have
> > > received this email in error please notify: [EMAIL PROTECTED]
> > >
> > >
> > >
> >
> >=============================================================
> ============
> > >=====
> > >
> > >
> >
> >=============================================================
> ============
> > >== To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the
> > > body of the message "signoff J2EE-INTEREST". For general
> help, send
> > > email to [EMAIL PROTECTED] and include in the body of
> the message
> > > "help".
>
> ==============================================================
> ================
> This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity
> to whom they are addressed. All information is the view of
> the individual and not necessarily the company. If you are
> not the intended recipient you are hereby notified that any
> dissemination, distribution, or copying of this communication
> and its attachments is strictly prohibited. If you have
> received this email in error please notify: [EMAIL PROTECTED]
>
>
> ==============================================================
> ================
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "signoff EJB-INTEREST".
> For general help, send email to [EMAIL PROTECTED] and
> include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
