Ok,I checked that. Allows me to perform any action I want after a
transaction has started, as well as before and after a transaction is
commited. I am a bit curious about the "obvious thing" you mention. I assume
I still need to deal with TopLink "Units of Works" or Transactions. How are
the two transaction mechanisms integrated?
Thanks,
Philippe
-----Original Message-----
From: Hal Hildebrand (Work) [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 12, 1999 11:34 AM
To: [EMAIL PROTECTED]
Subject: Re: Different beans/remote access
javax.ejb.SessionSynchronization. Simply implement the interface on your
bean and do the obvious thing when the methods are called.
> Hal,
>
> Now, you have go me excited here! We are planning to use ObjectSpace
Voyager
> Application server and may be TopLink for the O/R mapping. What is this
> SessionSynchronization interface? After speaking to people to TopLink, it
> was not obvious to me that having container declared transactions was that
> trivial?
>
> Thanks,
>
> Philippe
>
>
>
> -----Original Message-----
> From: Hal Hildebrand (Work) [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 12, 1999 9:24 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Different beans/remote access
>
>
> > Hal,
> >
> > The model you describe looks OK, but then I am not sure that EJB brings
a
> > lot to the table. Especially if the O/R mapping tool in not tightly
> > integrated with the EJB container. In this case, you do not get
> declarative
> > transactions. What about the integration of JTS bases distributed
> > transactions provided by the container and the O/R mapping tool own
> > transaction mechanism? Not sure about security... Looks almost like a
> > classical RMI or CORBA based architecture. Am I missing something
> (again)?
> >
> > Philippe
>
> Using the SessionSynchronization interface makes it trivial to tightly
> integrate the O-R tool into the container. This gives you all the
> declarative transaction capability of the container. If the O-R tool
> doesn't automatically generate this code, it's trivial to add to the bean.
> For example, it is really, really simple to do this using TopLink. Using
> BeanManaged transactions gives the control back to the O-R tool, if that's
> what you require.
>
> Security comes for free, and is no way changed by this scenario.
>
> As to the difference between the classical RMI/CORBA architecture, there
are
> four main differrences:
>
> 1) You don't have to write the container
> 2) You don't have to implement your own declaritive transactions
> 3) You don't have to implement your own security.
> 4) You don't have to re-invent yet another component architecture
>
> Yes, this is similar to the classic architecture, but all the hard
problems
> you'll have to solve over and over and over if you do this manually are
done
> for you in EJB. Also, using this method, it is portable to ANY EJB
> container which uses JDBC.
>
> This is the whole point of a component architecture. It's not rocket
> science. It's just boiling water the same old way. However, now everyone
> boils water the same way, and doesn't have to re-invent combustion every
> time they do it, or move to a different vendor.
>
> Writing servers for this model is still a very hard problem to solve, and
> simply using CORBA/RMI does nothing for you except provide the remote
> communications mechanism. Security, transactions, etc are completely left
> as an excercise to the developer.
>
> > > The problem is that we end up with:
> > >
> > > client --> statefull session bean --> stateless session bean -->
> entitity
> > > beans --> database
> > >
> > > Each arrow is a remote invokation, with the overhead of network
latency
> > and
> > > the marshaling and unmarshaling of data.
> > >
> > > May be I am missing something, but I can not see how a large system
can
> be
> > > implemented like that. If your application server provides optimzation
> > > whereby co-located beans end up calling each other using local method
> > calls,
> > > then at least you solve the performance hit. YOu still have to deal
with
> > the
> > > overhead of generating all these extra java files for each bean, even
> the
> > > dummiest and most passive one.
> > >
> > > Can anyboddy provide some useful insight on how to deal with this?
> >
> > client --> stateful session bean -> database
> >
> > Forget the entity beans. Use an O-R mapping tool in the stateful
session
> > bean for your domain entities.
> >
> > You're also forgetting in your budget analysis, the remote communication
> > substructure that is used for each bean. There's some ways to
amortorize
> > this cost, but none of the methods are as fast, nor as lightweight as
> simply
> > using an O-R mapping tool to manipulate the "entities" in the database
> while
> > in a stateful session bean.
> >
> > You can't beat the low overhead of this method, as doing nothing is
> > certainly always faster than doing something. Caching, pooling, and all
> > that fanciful stuff still costs. It's also complicated and ugly code
> that
> > sucks up resources. AND the entity implementation is undoubtedly using
> the
> > *same* or at least similar O-R mapping mechanism for the container
managed
> > persistence.
> >
> > You'd have to have a pretty darn good reason to give *every* one your
> > entities in the domain a communication/security/transactional identity.
> > "Because they are there and easy" is simply not a good enough reason,
> imho.
> > This is poor engineering - just my opinion.
> >
> > Good reasons for entity beans include federation of databases,
distributed
> > locations of the various application databases, wrapping of legacy
> systems,
> > etc.
>
>
===========================================================================
> 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".
>
>
===========================================================================
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".
