The problem is that your beans have to be designed for both read and write
modalities. Separating read/write operations into different components is
not ideal, and although it is cute to allow the container to allow
read/write operations to be cataloged declaritivly, I fear this is a brittle
approach. What happens when through re-factoring a method that previously
was read only, suddenly has a side effect that implies a write? This is
particularly problematic if the side effect only happens under certain
conditions.
Also, this is exacerbated when we have user think time which is most likely
outside of transaction. Pessimistic concurrency does us no good in this
modality which is the most prevelant in oltp.
For all these reasons I strongly advocate a general pattern of using
optimistic concurrency, with dirty detection at write time. The underlying
datastores pessimistic mechanisms can be used to handle the case where two
optimistic transactions are in flight at the same time.
<vendor>
We cover this and other key design and architecture patterns in our
Developer's Guide. You can register for this at our WEB site.
In our humble opinion, your projects success will have a lot more to do with
software engineering process, team skills and dynamics, and leveraged design
patterns than it will be based on application server vendor tricks. Is your
vendor telling you the whole story? Of course you need a solid platform, but
your success will be based on how you use it. You can make a mess out of the
best technology! No silver bullets.
</vendor>
Regards,
-Chris.
> -----Original Message-----
> From: Asha Balasubramanyan [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, February 17, 2000 5:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: What is pessimistic and Optimistic concurrency?
>
> Jean:
> when we do pessimistic and optimistic concurrency ? i would say for
> read
> only operation container can do optimistic and for mutators it should do
> pessimistic . Can we enforce the container to do this kind of things. i am
> new to EJB and trying to understand what the container does when we do
> transactions .
>
> Thanx : Asha
>
> -----Original Message-----
> From: Jean-Baptiste Nizet [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 17, 2000 1:27 AM
> To: [EMAIL PROTECTED]
> Subject: Re: What is pessimistic and Optimistic concurrency?
>
>
> Suppose you have an entity bean representing an account. This account is
> owned
> by several people, each of them being allowed to perform operations on the
> account.
> Now suppose that two of these people start a transaction and try to access
> the
> bean.
> If pessimistic concurrency is used, then the first one who uses the
> account
> bean
> will obtain a lock on this bean. The other one will have to wait until the
> first
> transaction ends before to be able to perform an operation on the bean.
> That
> way, you'll be sure that the information that you get in the bean is
> accurate
> information, and that you'll read the latest state of the bean. On the
> other
> hand, if the two persons just want to have the balance of the account
> (read-only
> operation) and if the first transaction is long, then the second person
> will
> have to wait for nothing.
> Now if optimistic concurrency is used, then the two persons will be able
> to
> access the bean simultaneously. There will be no lock on the bean itself.
> If
> the
> operations they perform are read-only, no problem. Now if the operations
> they
> perform update the state of the bean, it can lead to problems. For
> example,
> if
> the two persons increment read the initial balance (5000) and then
> increment
> it
> (+1000), instead of having a final balance of 7000, the account will have
> a
> final balance of 6000. Now depending on the configuration of the database
> transaction isolation level, and on other configuration options the
> container
> might provide you, the second transaction could fail and rollback, and you
> might
> have to retry the transaction.
>
> Hope it was clear.
>
> JB.
>
> P.S. : to the maintainer of this mailing list : is it normal that I don't
> receive the messages I post. It's rather annoying to have incomplete
> threads
> and
> not to be able to easily find the reactions to your posts.
>
> Asha Balasubramanyan wrote:
>
> > Hi:
> >
> > In this forum in lot of disccusions , i heard Pessimistic/optimistic
> > concurrency , can anyone tell me what this means?
> >
> > Thanks
> > Asha
> >
> >
> ==========================================================================
> =
> > 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".
>
> --
> Jean-Baptiste Nizet
> [EMAIL PROTECTED]
>
> R&D Engineer, S1 Belgium
> Excelsiorlaan 87
> B-1930 Zaventem
> +32 2 714 45 42
>
> ==========================================================================
> =
> 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".
