(I sent a reply to this post earlier, but it seems to have been
discarded by the mailserver... typical..)
> IF you use a session bean, it must load all the records, serialize them
> and return a serialized copy. So you get the overhead of serialization
> (which is pretty significant) and you don't benefit from the value of
> fetch buffers (which gives bettern response time).
This is not necessarily correct. A bean could return a RowSet. There's a
tutorial on this on the JDBC homepage. The RowSet could either be
pre-fetched, or it could do fetching as needed. This would allow you to
use only EJB's to interface with your model, instead of doing
servlet-JDBC workarounds.
Far-out idea:
Shouldn't it be possible to have methods in EntityBean home interfaces
that looks something like this:
RowSet getDisplayData()
* When called it could get data for that particular EntityBean,
according to some declarative info about what attributes and what "rows"
should be returned.
* Since this is in the EntityBean interface the container can make sure
that the data is correct, either by first synching all cached instances
with DB, or by synching the data from the db with the data in the live
entity instances (either will give proper results).
* This will be a solution for having some interaction through
entitybeans and some through JDBC accesses. Now all calls to the
"logical" entity goes through the entitybean interface.
Am I missing something or could this really work?
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.dreambean.com
Question reality
===========================================================================
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".
