I've been strugling with some design issues with our current application.
It's written using RMI and allows good concurrency control by passing
objects by value to the clients. This allows clients to make changes to the
same record. At the point of client saves, the object is passed by value
*back* to the server for persisting. Two of the same objects are persisted
if the clients didn't alter any of the same fields. Our objects inherit from
a superclass that provides all of this functionality.
I guess this is the sticky point with most applications that we find
ourselves developing. While this works well, it's far from utilizing a
framework, and further from what EJB has to offer. RMI is sadly
undersupported in the Application Server environment, not to say the Valto,
WebLogic, and other folks don't have great products. But the majority of
companies that I am in touch with, have fully embraced CORBA and the App
Servers built upon it.
Which brings me back to our design struggle, what to do with session beans?
In the EJB world (as it stands right now) the developer is encouraged to
have one instance of each unique entity bean available to clients in the
system. If two users are working on the same entity bean, it destroys any
semblance of concurrency control. I guess I see the session beans as holding
a data structure that can be mapped back to one or more entity beans. When
the clients are completing a form [which may impact the same entity bean(s)]
their intermediate changes can be kept in their session bean. When it comes
time to save, the session bean writes the values it is holding to the
appropriate entity beans with the full-transaction support that is
necessary.
I do see some problems with this approach (and non-pass-by-value
approaches).
1. Very high network chatter between client and session bean. This is
especialy true when the clients employ a MVC design. MVC causes GUI
components to be painted more often than they would normally. This is not an
issue if the data is held locally, but it can cause a great deal of network
chatter. I would hope that some enterprising EJB vendors would provide some
sort of session-bean proxy, either as a pass-by-value object, or as a
struct. This proxy is sent to the client and holds values locally as they
are requested. Of course this can be implemented now, but it would be great
if an EJB vendor made it an automatically generated class.
2. If two requests to change an entity bean arrive simultaneously,
transaction control will make sure that the changes are ACID. However, there
is no mechanism to let the second transaction know that the object has
changed since they last used it. Most of the time, applications try to let
clients know that the object has changed since they last received their copy
and doesn't allow the write to occur. IMO, the write should occur as long as
the client #1 is not changing a field that client #2 has modified since
client #1 obtained his values.
corse grained = more frequent
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Imre Kifor
> Sent: Saturday, May 15, 1999 11:12 PM
> To: [EMAIL PROTECTED]
> Subject: Real advantage of session bean wrappers?
>
>
> Considering recent postings, I must ask the question:
>
> "Is there any real advantage to wrap entity beans with session beans?"
>
> Here are the reasons for my question:
>
> - some posters have questioned the validity of encapsulating conceptually
> related data inside two or more beans. I strongly agree with them.
>
> - some posters have questioned the much publicized performance gains when
> calling session beans as opposed to entity beans. I strongly agree with
> them; a remote call is a remote call.
>
> - some posters have questioned the "special capabilities" attributed to
> session beans (as opposed to entity beans) "when it comes to
> accessing ejb's
> of any type", returning custom data or dealing with transactions.
> I strongly
> agree with them.
>
> - some posters have complained about having to wrap all client calls to
> session objects in try/catch blocks to deal with session object
> expirations
> thus making client logic convoluted and client code brittle. See
> my previous
> posting.
>
> - some posters have complained that ad-hoc data already resident on the
> server cannot be cached and shared among different clients. We avoid using
> session beans for sharable or not client related data.
>
> - I stated that session beans are conceptually more expensive on
> the server
> than entity beans (the server has to manage timeouts).
>
> - I raised the issue that some platforms cannot conceptually reclaim
> unreferenced entity objects thus leading to resource exhaustion.
>
> I certainly hope, based on the above, that some posters of this
> list are not
> simply glorifying a platform shortcoming (i.e. not being able to release
> entity objects thus forcing the use of session objects) into full fledged
> paradigms of EJB usage.
>
> VERY IMPORTANT NOTE: Since wrapping of entity beans into session
> beans is a
> usage paradigm and the above conceptual flaw is a platform characteristic,
> the EJB architecture (and spec) is not questioned. Furthermore, session
> beans are complementary to entity beans and both are necessary for
> implementing feature complete solutions.
>
> Imre Kifor
> Valto Systems
>
> ==================================================================
> =========
> 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".
>
>
===========================================================================
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".
