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".
