Gary Swatton wrote:

> Chip,
>
> Thanks for the information.  Do you have any "code samples" which are not 
>proprietary that I can take a look at?  Also I have some questions.

No code that I can share.  Sorry.

>
>
> I have developed a ClientSessionManager object which maintains a list of the clients 
>using the client Identity.  Each ClientSession object is a SessionBean which is 
>created by an RMI Server component upon User login.  The EntityBean's can then lookup 
>up the appropriate ClientSession within their methods.  The ClientSession SB's 
>implements the SessionSynchronization interface and creates the UOW for the user 
>within the afterBegin() method and commits and/or rolls back the UOW in the 
>beforeCompletion() method.  Below are a couple of specific questions:
>
> 1.  You say you store the user's UOW within the User's context.  How do you do this? 
> I wasn't aware that you could put data in the User's context.  That's why I created 
>a ClientSessionBean to store the client's state information.

The user context object I refer to is an application object we created.  I don't see 
the need for session beans to maintain this information.  I implemented a manager 
using the singleton pattern which stored a user context object for each user keyed by 
the Identity object.  This user context object keeps track of the TL UOW as well as 
the TL ClientSession object.

BTW, there is a problem with committing the TL UOW in beforeCompletion.  This method 
is essentially the same method as ejbStore for most servers, so if you have two entity 
beans accessed from a transactional session bean method, you are not guaranteed that 
beforeCompletion will be called after ejbStore on each entity is called.  If you do it 
in afterCompletion, it is too late to roll it back.  That is why I implemented a JTA 
transaction resource that functioned as an adapter to the TL UOW, commiting the UOW in 
the prepare call to the adapter.

>
>
> 2.  My thought was to have the ejbCreate() method of the EB's look up the 
>ClientSession and register "empty" objects at that time and get the PrimaryKey.  TL 
>should be able to return a new PrimaryKey (next identifier) even though there is no 
>data in the object.  Then when EB's ejbStore() method gets called, you can merge the 
>copy of the real object into the ClientSessionBean and corresponding UOW.  Can you 
>think of a reason why this might not work?  I would think this would eliminate the 
>need to keep track of the changed domain objects for each Entity Bean, since the 
>corresponding ClientSessionBeans and associated UOW's would deal with the issue, 
>won't they?

Hmmmm.  I still don't see the need for a session bean, but I'm not saying it won't 
work either.

>
>
> 3.  Was the effort worth the result?  I would love to just use CMP, but given my 
>multiple EJB Server requirement and lack of a standard Container mechanism, I think 
>TOPLink is probably the best way to go.  However, it's not too late to change 
>directions, and if you have any reasons why we should not continue with this approach 
>I would love to hear them.

I favor coarse-grained entity beans that serve as a facade to a graph of domain 
objects (see my article in the August issue of Component Strategies, "Application 
Architecture with EJB").  With this approach, you need a good O/R mapping framework.  
Many CMP implementations assume a one-to-one mapping between entity beans and database 
tables.  It is my opinion that this approach is flawed from multiple architectural 
views.  This subject, however, has been debated at great length on this list, and I do 
not wich to open it up again.  See the archives for more details.

>
>
> 4.  How did your overall system perform?  I don't know all of the details and 
>overhead of TOPLink and EJB, but TL says to expect a 20% degradation and EJB has 
>overhead, so I would expect some.  Did you find that the "developmental cost savings" 
>and TL's UnitOfWork and caching mechanisms performance saving make up for the 
>overhead?

That is way too complex of an issue for me to address here.  Let it suffice to say we 
were able to meet our performance requirements.

>
>
> Thanks,
>
> Gary
>
> >>> Chip Wilson <[EMAIL PROTECTED]> 09/08/99 08:25PM >>>
> Hi Gary,
>
> I implemented a large system currently in production using BMP and TOPLink for Java 
>(not WebLogic).  I can't go into all the gory details, but in short this is what we 
>did:
>
> Implement all transactions (system operations) on session beans as TX_REQUIRED.
> Any entity bean method that modifies the domain should be set to TX_MANDATORY.
> Set all bean methods everywhere to CLIENT_IDENTITY.
> Provide a user login method on a session bean.
> Implement a user context dictionary that keeps track of all the currently connected 
>users by their Identity/Principle.
> When a user logs in, create a TOPLink client session for them.
> Implement the SessionSynchronization interface in all session beans.
> During afterBegin, look up the TOPLink client session by the caller's identity, 
>create a unit of work for the user, and store it in the user's context.  Also 
>register a transaction synchronization adapter using the server's JTA implementation 
>(or equivalent).
> As entity beans change, keep track of the changed domain objects in a collection for 
>each entity bean.
> During every ejbStore, look up the UOW by the caller's identity and merge the 
>changed objects into it.
> When the transaction adapter gets a prepare call, commit the TOPLink unit of work.  
>If an exception is thrown, vote to rollback.
>
> There are a lot of little things you will have to deal with, like the fact that 
>ejbCreate has to return the primary key of a new entity, but (if you are using 
>sequence generators in the database) TOPLink won't generate the PK until the 
>transaction is committed.  We were able to solve al these problems, but I can assure 
>you that the overall task of integrating TOPLink with BMP is non-trivial.
>
> Most of the code can be implemented in abstract super classes, so that individual 
>bean's don't know anything about all this.
>
> Good luck!
>
> --Chip
>
> Gary Swatton wrote:
>
> > Hi Chuck,
> >
> > Are you using TOPLink (TL) for Java 2.0 or TOPLink for WebLogic?  Are you 
>utilizing UnitOfWork (UOW) within your EntityBeans (EB) or just utilizing TL's 
>Sessions?
> >
> > I haven't been able to figure out how to set up my EB's to utilize UOW's (because 
>EB's are shared and by definition, UOW's are one per user).
> >
> > I've tried to set up the UOW's encapsulated inside a SessionBean (SB) per client, 
>but don't know how to identify which Client is modifying the EB from the Server EB.
> >
> > Any insight would be helpful.
> >
> > Thanks,
> >
> > Gary
> >
>
> ===========================================================================
> 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".
begin:vcard
n:Wilson;Chip
tel;fax:(214) 358-0353
tel;work:(214) 642-4559
x-mozilla-html:TRUE
url:http://www.axyssolutions.com/
org:Axys Solutions
adr:;;;Dallas;TX;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Application Architect
note:Sun Certified Java Architect
x-mozilla-cpt:;-25088
fn:Chip Wilson
end:vcard

Reply via email to