ServicedComponents vs EJBs

TC brings up a good point...

"A session bean object is a short lived object that executes on behalf of a single client.There are stateless and stateful session beans. Stateless beans don't maintain state across method calls. Any instance of stateless beans can be used by any client at any time. Stateful session beans maintain state within and between transactions. Each stateful session bean object is associated with a specific client. A stateful session bean with container-managed transaction demarcation can optionally implement the SessionSynchronization interface. In this case, the bean objects will be informed of transaction boundaries. A rollback could result in a session bean object's state being inconsistent, then implementing the SessionSynchronization interface may allow the bean object to update its state according to the transaction completion status."

[Developing Session Beans]

So Java can do it, why not .NET? A bunch of COM+ fans don't seem to think it is a big deal, but it was obviously a big enough deal for EJBs to take it into account.

2 Comments

  • (Posting this here, as I didn't see this entry when I wrote this comment.)





    COM+ does provide a partial solution to this problem, if you wish. Object pooling allows you to maintain certain elements of your state when the transaction completes. The feature was designed, in fact, both to amortize the cost of aquiring expensive resources, and to provide constraints on the number of those resources that exist at any one time.





    If you mark your component as pooled, then you can aquire your resources in your constructor, do any work that would require the current transaction in Activate(), and release (or clear) those bits of state in Deactivate(). Note that this does not change the recommended usage pattern from the client's point of view, and the interface described above still won't work (exactly). When the client calls the AutoComplete method, your object will STILL be deactivated and placed back in the pool. When the client calls another method, it will receive a new object out of the pool, and that object may or may not have already had one of the Initialize* methods called on it. Therefore, a client must always be sure to call one of the Initialize* methods before calling Ship.





    But you can still cache your state inside your object, which may be what you want.





  • Yah, object pooling is definately better than nothing, but still would be nice to have the same type of features that EJBs offer in this area (never thought I would say that).

Comments have been disabled for this content.