As you collect your order, add the line items to a statefull bean with out a
transaction - that way you can take as long as you want to gather the data.
Once you are done assembling the order, invoke a transactional method on the
statefull bean that applies the changes to the database.
--
Richard Monson-Haefel
Senior Consultant
BORN Information Services
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
(Available June 1999)
Sachin Aggarwal wrote:
> Hasko,
>
> Why we need client demarcated txns - Here's how I look at it:
>
> Typical scenario for our ecommerce web site: A user creates an order with
> multiple orderlines and each orderLine object has a productSpec and
> deliveryInfo object.
>
> There are 3 options: It looks like most seem to prefer Ist option but
> currently I feel there's benefit using the 2nd option for our system.
>
> Option1: The system collects all the data while going from one web page to
> another and then when done all the data is sent to the server probably via a
> method on a session bean.
>
> A disadvantage of this is that if the orders being created are complex
> custom orders and require a lot of other objects to be created, then this
> approach requires creating serializable complex datastructures ( almost a
> virtual database ) and passing it from the client to the server.
>
> The advantages are that this approach provides good performance and there is
> only one call over the wire. Also there is no locking on the server side
> which can be good for performance but bad as far as business logic is
> concerned..
>
> Option 2: The system collects all the data while going from one web page to
> another and then when done starts a client demarcated transaction , makes
> multiple calls creating order entity , orderLine entities , productSpec
> entities , delivery entities and then commits the transaction.
>
> The advantage is that you don't need complex data structures.
>
> A big advantage is that you talk to multiple session beans and entity beans
> within the same transactional context and don't have to worry about having
> one method to wrap up all the work that needs to be done .
>
> Disadvantage is that there are multiple calls over the wire.
>
> Another advantage is that there is no client interaction between start and
> commit of the transaction and so it shouldn't create a performance problem.
>
> Option3: When creating or changing an order, the client starts a
> transaction, and while going from one page to another it makes a call to the
> server sending it the info collected and then when done it commits the
> transaction.
>
> The advantages of this approach are that of option 2 with the added
> advantage that now there is no need to pass lots of data from page to page
> or save it as session data and then retrieve it before sending it to the
> server.
>
> The disadvantage is that it creates a performance problem which can be eased
> if you use oracle as the pStore since it provides optimistic concurrency
> but there is still the issue of locked beans.
>
> sachin
>
> [EMAIL PROTECTED]
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Hasko Heinecke
> > Sent: Tuesday, April 20, 1999 12:43 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: simultaneous JTS transactions from ASP
> >
> >
> > Sachin,
> >
> > you wrote:
> > > We are using ASP on the client side to talk to the EJB server.
> > > Anybody know how we can start client demarcated JTS
> > > transactions in seperate
> > > threads from ASP ?
> >
> > Maybe someone already asked that, but I'll just ask anyway: Do you really
> > need client demarcated transactions? Usually you only need this
> > when you're
> > adressing several transactional servers from the same client
> > thread or when
> > transaction begin and commit are separated by user interaction.
> > Is this the
> > case for your application?
> >
> > Hasko
> >
> > ==================================================================
> > =========
> > 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".
===========================================================================
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".
