re:entity bean
> is not a *very* heavyweight object by its nature. It takes no more time to
> pull an entity bean out of a pool, than it takes to pull a SLSB.
well, consider a clustered server environment where you will have to keep
transactional locks synchronized across servers in a distributed
transaction.
at this time, an entity bean is A LOT HEAVIER than a SLSB. I know that an
entity bean is still just a Java object, but that is not what I was
referring to.
that is what I mean about heavy weight.
> Even if I had a simple 2 column table of reference data, I would still
> choose to represent this as an entity bean in most systems. There are
> exceptions of course, but if the reference data can *ever* be
> modified, then
> an entity bean is the appropriate structure.
I would only do this if I had clients that needed to access the data
concurrently and the database transaction manager was not enough, but I had
to do it on a object level.
in most cases, the database transaction implementation is enough. Far to
many dot-coms had to rearchitect their systems because of scalability issues
around entity beans.
Filip
~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
[EMAIL PROTECTED]
www.filip.net
===========================================================================
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".
