On 2001.05.02, Tom Jackson <[EMAIL PROTECTED]> wrote:
> Dossy wrote:
>
> > What happens if the database update succeeds, but somewhere between
> > the update and the kill/remake of the bean, the process fails?
> >
> > Now, the data is out of sync.
>
> Hopefully the data being used by the bean in this way can be relatively
> up-to-date, for instance today's headlines.
That's not the point of ACID. If you're not building a site that
needs to meet ACID requirements, then almost _anything_ will do
just fine, that includes EJB.
Just as folks argue against MySQL "if you MUST have something that
passes the ACID test", the same arguments can be made against EJB.
Which is exactly why I find the "E" in EJB quite a misnomer. It's
not suitable for building serious Enterprise level applications,
at least not those that must pass the ACID test.
> As long as the db passes the ACID test, that is all that matters.
Be glad the people who design web interfaces to stock trading systems
don't share your opinion. ;-)
> Don't use the data in the bean for anything important, don't hold it
> there and re-display it before committing to the db, and grabbing the
> update.
If you're not using Beans for important things, then why do you need
to use Beans at all?
> I don't see any real difference between a bean and a nsv_ element.
> Probably the bean is a little more flexable, but it is all virtual
> memory.
The difference is that Beans offer you a layer of abstraction, which
in the extreme performance demands of the Web arena, translate into
unnecessary performance hindrances and overhead.
- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
