hi,
I am not sure if this would work, but how about this ugly approach (works
for mostly-read-only access):
-use fine-grained CMP Entities
-use ejbdoclet to generate CMP implementations for these Entities
-use Value Objects (or Data Objects, Data Holders - same thing - these get
generated by ejbdoclet, you don't have to write them)
-write additional doclet to generate Session beans with finders with JDBC
code in them, generated from the same declarations in comments of abstract
Entities.
-these finders should return *Data Holder collections* instead of remote
interface collections
these session beans should be used for retrieving large result sets for
read-only access.
in case you need to create new/update/remove existing records in db, you
just use the CMP beans - call create() with your data or look it up using
the primary key and update the desired fields or remove the record totally.
I recognize this would break the integrity of data in some cases, but in web
environment this would work IMHO - you only see the actual snapshot of data
anyway.
I suppose this should break the ejb model somehow, but it would certainly
make the life easier if it worked out ;)
what do you guys think?
--andrius
:-----Original Message-----
:From: [EMAIL PROTECTED]
:[mailto:[EMAIL PROTECTED]]On Behalf Of Kenworthy, Edward
:Sent: Monday, January 22, 2001 4:24 PM
:To: 'jBoss'
:Subject: RE: [jBoss-User] HOWTO: Replacing Entity with Session bean
:andma nage the persistence
:
:
:Hi Christophe
:
:This is what we have done. And its for more than just performance.
:It's also
:about control (over the database), performance (we've implemented demand
:loading) and portability.
:
:The only major disadvantage I can see is you lose container caching. Which
:is a big deal if you regularly have several clients accessing the same
:entity instance at the same time, but otherwise isn't.
:
:Obviously an email is too small to handle this but in outline:
:
:Session bean as usual (stateless in our case and correspond 1:1 to our use
:cases). Entities (christened Big Beans) are simply normal java classes
:referenced by the session bean. (Even if I was using EJB Entitys I would
:have the same session beans). All entities derive from AbstractEntity and
:have a corresponding EntityPS class that handles persistence (and
:is in turn
:derived from AbstractEntityPS). All but the most trivial relationships are
:handle by an instance of a sub-class of AbstracyProxyList and has a
:corresponding ProxyListPS class that persists the relationship. The proxy
:lists handle the demand loading.
:
:Hope this helps.
:
:Edward
:
:-----Original Message-----
:From: [EMAIL PROTECTED]
:[mailto:[EMAIL PROTECTED]]
:Sent: 22 January 2001 14:10
:To: [EMAIL PROTECTED]
:Cc: [EMAIL PROTECTED]
:Subject: [jBoss-User] HOWTO: Replacing Entity with Session bean and
:manage the persistence
:
:
:Hello,
:
:I have heard several time that it is possible to replace the Entity Beans
:with Session beans, why :
:- for perfomce improvement !
:
:So, I m searching for information about this !
:More explaination about this principle, perfomance comparison, ...
:What are the advantage of each, if there is some problem to have complex
:structure, queries, ... with this solution !!
:
:Thanks for all your help
:
:Christophe
:
:
:
:--
:--------------------------------------------------------------
:To subscribe: [EMAIL PROTECTED]
:To unsubscribe: [EMAIL PROTECTED]
:List Help?: [EMAIL PROTECTED]
:
:
:--
:--------------------------------------------------------------
:To subscribe: [EMAIL PROTECTED]
:To unsubscribe: [EMAIL PROTECTED]
:List Help?: [EMAIL PROTECTED]
:
:
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
