-----Original Message-----
>From: Andrius Juozapaitis [mailto:[EMAIL PROTECTED]]
>Sent: 22 January 2001 18:08
>To: jBoss
>Subject: RE: [jBoss-User] HOWTO: Replacing Entity with Session bean and
>manage the persistence
>
>
>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
Stop right there ! EJB Entites are expensive for the container to manage.
Have lots of teeny entities and you'll overwhelm the server.
>-use Value Objects (or Data Objects, Data Holders - same thing - these get
>generated by ejbdoclet, you don't have to write them)
That's what we're doing. You have to be aware that there are issues with
this approach, the first being that you have to duplicate the EJB entity's
structure, more or less, in the value object (breaking encapsulation).
Second is locking.
>-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
Yuch. This sounds like the approach we initially took, eg use the container
to the full (eg cmp) and the kludge everything around it to make it work.
Don't do it.
>these session beans should be used for retrieving large result sets for
>read-only access.
Personally I dislike these kind of tiny session beans. They lead to
fragmented systems.
>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
This goes against one of the most basic patterns in EJB design - allow
access to your entities only via session beans.
>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.
Uhm. So what you're saying is, don't do the job properly because we're only
developing for the web ?
>I suppose this should break the ejb model somehow, but it would certainly
>make the life easier if it worked out ;)
<EXASPERATEDTONE:ON>What more can I say.<OFF>
>what do you guys think?
I think it stinks.
Edward
:-----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]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
