"Dezulian, Tobias" wrote:
> * as far as I understand the Spec there's no way for EJBs to fork()/spawn
> new threads.
> Isn't that a big deficit cause it prevents scaling ? What did I miss here
> ?
The opposite, this is what makes it possible to scale EJB's: the more
control the server has the more possibilities are there to do
optimizations. If you need to do asynchronous processing use JMS with
EJBs as message producers/listeners.
> * entity beans map database rows.
> In my experience ( WebSphere ) that's incredibly slow. Far too slow for
> any serious application accessing a DB.
> Any thoughts on that ?
Yep, bad implementation. 8-) It is possible to implement entity beans to
use alot of caching and without unnessesary load/store on transaction
begin/commit, in which case you wont touch the db *at all* for
frequently used objects and read-only transactions. Which of course
gives extremely good performance. And the "entity beans map database
rows" part is only true for simple implementations of CMP. If you use
BMP or some O/R CMP implementation you can do whatever you want.
Keep apart implementation and design. They are only the same in the
Microsoft world :-/.
Hope this helped :-)
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
