db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Mogley" <mmog...@adelphia.net>
Subject PersistenceBrokerEjbClient
Date Wed, 24 Mar 2004 23:38:04 GMT
All,

I'd like to write a PersistenceBroker implementation that acts as a client to a PersistenceBroker
EJB session bean.  

For remote clients such as Swing apps (and even server-side business objects accessing a remote
EJB), there are currently major scalability issues related to RMI and serialization.  I know
the recommended approach is to use DTOs as go-betweens for the client GUI and server-side
domain objects.  However, doing this in practice implies having the client layer forgo all
the benefits of object-traversal and lazy-loading that a framework like OJB offers for domain
objects.

What I propose is the following: a PersistenceBroker implementation specific to client-side
code where access to the server-side objects is remote and must therefore incur the overhead
of RMI.  A use case will illustrate the mechanics of what I mean:

Consider the following classes:

- Album [ID<Integer>, name<String>, description<String>, coverPhoto<Photo>]
- Photo [ID<Integer>, name<String>, description<String>, album<Album>]

Use Case: client reads Album for given ID and updates Album.name

1) client queries PBEjbClient for Album with given ID
2) PBEjbClient forwards call to PBSessionBean to retrieve Album with given ID.
3) PBSessionBean retrieves given Album and serializes, skipping proxied fields (such as coverPhoto,
which is a persistent object mapped to another table)
4) PBEjbClient deserializes Album and returns instance to client
5) client sets Album.name and calls PBEjbClient.store(album)
6) PBEjbClient retrieves Album.ID, Album.timestamp, and the only dirty PersistentField from
Album (Album.name) and wraps all three in a DTO
7) PBEjbClient serializes DTO and sends to PBSessionBean
8) PBSessionBean deserializes DTO, retrieves Album for the DTO's ID, and compares the timestamps.
 If Album.timestamp is newer, it throws back a StaleObjectException (which is propagated to
client).  Otherwise, it updates all fields in the Album to the corresponding DTO field values.

Obviously, this would be more complicated if the coverPhoto was defined and parts of it were
also dirty (but then the approach above could be modifed to use recursion).

I am anticipating a project in the very near future that uses distributed EJBs and rich clients
and so have an immediate need for such a feature.  I'd like develop this myself and contribute
back to the codebase once I'm satisfied everything works.

I need guidance on this.  Has some work already been done that I should look into?  Is my
approach all wrong?  To enforce the requirement for objects participating in remote updates
to have timestamps, I plan to have a PersistentObject interface.  Would this be terribly wrong,
in light of the goals of transparent persistence?

Thanks for your humble opinions,

Michael
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message