We considered this approach.
This approach would require creating the data structures arrays/vectors in
the session bean . That itself may not be a bad idea if the entity beans
have and extend their respective data structure classes.
Also consider a case of updating a specific order : Adding a new
orderLineItem , changing another lineItem's quantity and it's delivery
address. So we would pass in 2 orderLineItemInfo and a deliveryinfo and then
when the ok method is called the session bean actually creates one new
entity, and for other 2, finds them and updates them . While updating the
existing entities , it'll have to call all the settors. It'll work but can
be painful.
> 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".
>
>
===========================================================================
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".
