The J2EE spec states that you are not allowed to call the
setTransactionIsolation method.

/Johan

citerar SAMINATHAN <[EMAIL PROTECTED]>:

> Dear Mr Krishnan
>
>            Thanks for your reply first.But in our case CMP is ruled
> out.Since we had a very complex parent--child relationship in our
> application, we did not have any other option other than opting BMP
(EJB
> 1.1
> spec) .
> Any way we are in the verge of completing our project, so i wanted to
know
> by setting setTransactionIsolation() in my entity can i avert the
> concurrency or not?.Since i tried to do that but i don't know how to
> simulate the concurrent access.Hence am not able to verify.
>
> Thanks and Regards
>
> Saminathan.
>
>
> ----- Original Message -----
> From: "Krishnan Subramanian" <[EMAIL PROTECTED]>
> To: "SAMINATHAN" <[EMAIL PROTECTED]>
> Sent: Monday, March 11, 2002 2:58 PM
> Subject: RE: Re: basic transaction management and isolation level
question
>
>
> > Saminathan,
> >
> > In the case of BMP, you (that is, the developer) is responsible
> > for managing concurrency and consistency of data. So, you would
> > have to take the above into account if you want to write 'bullet
> > proof' BMPs that are safe when accessed concurrently by multiple
> > transactions.
> >
> > But in the case of CMP, it is as simple as turning on a flag (in
> > the deployment descriptor) to tell the Container what kind of
> > strategy to use. (For example you could tell it to use verified
> > updates and/or you could tell it to use Oracle's syntaxt "Select
> > ... For Update" for locking etc. And in the case of BMP, you'd
> > have to handcode all these which takes time & effort. EJBs are
> > supposed to aid developers in developing business components and
> > not let the developers worry about lower level system issues such
> > as persistence mechanisms and strategies. Also, if you handcode
> > these - as in the case of BMP - you'd probably have to recode when
> > you switch databases to one that supports a different locking
> > strategy).
> >
> > It is best to avoid BMP. The performance of CMP is almost 2x times
> > faster than its BMP counterpart. CMP code is also cleaner, more
> > readable and easier to maintain & port than BMP. The Container also
> > can perform optimizations - simply because it has control of when
> > and what SQL code to execute (or not to execute) . But if you write
> > BMP, then the Container has no control - and hence the possiblity
> > of optimizing BMP code (by the Container) is reduced greatly.
> >
> > -krish
> >
> > > -----Original Message-----
> > > From: SAMINATHAN [mailto:[EMAIL PROTECTED]]
> > > Sent: Saturday, March 09, 2002 5:52 AM
> > > To: Krishnan Subramanian
> > > Subject: Re: Re: basic transaction management and isolation level
> > > question
> > >
> > >
> > > Hi Krish
> > >
> > >       I got a chance to go thru  your design  pattern white paper
from
> > > Borlando Site.
> > > The  very interesting aspect in that how Borlando Managing the
> Concurrency
> > > issue, that's fantastic in case of CMP.
> > > But i would like to know how your server will behave if it is a
> BMP.Will
> it
> > > take care by iteself. I guess no.If it is not
> > > do i need to set any transaction level in SLSB or Entity.
> > >
> > > I am eagrly waiting for your Reply.
> > >
> > > Thanks and Regards
> > > B.Saminathan,
> > > System Analyst,
> > > House of  Code pvt(I)  Ltd,
> > > Bombay.
>
>
========================================================================
===
> 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".

Reply via email to