tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: AW: Store data in SessionContext
Date Thu, 19 Jun 2008 20:29:34 GMT

Gilbert makes a good point here, but I don't agree with all of it....

When using a static field in a enterprise application (e.g., EJB,  
servlets, web-services, enterprise spring), you should be aware that  
the static field will be private to each running instance of the  
application.  So if you have 100 VMs running your application, each vm  
will see a different copy of the static variable.  In the case you  
laid out below, this is acceptable.

As for the rest... I disagree.  This is a complex subject so please  
bear with me.  In JEE a application is not really a divisible unit.   
This is really due to the introduction of local interfaces in EJB  
2.0.  In EJB 1.x you only had remote interfaces, so a server could  
theoretically deploy an application with thee EJBs to three VMs with  
one EJB on each VM.  In EJB 2.x, a servlet or EJB can obtain a direct  
local interface to a bean and pass non-serialzable data to the bean.   
Whit the introduction of JPA in EJB 3.x the application has become  
even more coupled.   This means that unlike EJB 1.x an application  
server can not blindly distribute the EJBs in an application across  
multiple VMs.  To automatically distribute the EJBs in an application,  
the server would have to perform some very complex static analysis to  
determine which components are making direct calls to other  
components.  I'm not sure this is even possible, and even if it were,  
I don't think you would want to do it.  A distributed call is very  
very slow, fault prone, and involve distributed transactions.  The  
last point is particularly nasty as many databases don't properly  
support distributed transactions and when there are machine failures,  
part of you database can be locked until the transaction log on the  
failed machines are recovered.  Of course, you can always manually  
divide up your application into a group of applications that work  
together, and in that case you will be aware of the application  
boundaries and the costs of crossing them.  Also, never count out IBM,  
expecially when running on their most expensive hardware... they can  
do magic you've never even dreamed of.  Unfortunately, if you want to  
run on other (less expensive) systems, you can't expect magic.

Assuming that you agree that a JEE application can not be  
automatically divided up by the server, how do you achieve scaling?   
Well you can divide you application by hand and/or you can use  
horizontal scaling.  In a horizontal scaling, you run several VMs and  
each VM has the same application code running.  When a client request  
comes in, a request router chooses a VM and forward the request to the  
VM.  Since each VM is running the exact same code the router could  
theoretically pick a random node but since most applications use  
either client-session data or have data caches (like JPA or  
Hibernate), the router typically uses a sticky load balancing rule  
that forwards all requests from a single client to the same machine.   
Why sticky?   Well, when you have client-session data, it is becomes  
very expensive to transfer the client-session state state for each  
call.  Even more critical to performance, a client typically accesses  
the same or closely related data over their session, so if you send  
them to the same machine, there will be less cache faults (this is  
super critical to DB applications).

For the request router, you can use something as simple as a web load  
balancer assuming the clients always use HTTP to communicate with the  
server (this is my recommendation).  Alternatively, there are products  
like WebSphere XD Dynamic Router that can perform routing for many  
different kinds of protocols (like CORBA).

Hope that helps, and wasn't too confusing


On Jun 19, 2008, at 8:19 AM, Gilbert Carl Herschberger II wrote:

> Does any implementation of EJB container automatically distribute  
> beans? Yes, IBM WebSphere.
> IBM WebSphere comes bundled with IBM i Series and z Series. For  
> example, it provides support for distributing EJBs across a farm of  
> containers, with a load-balancing and fail-over monitor. With an EJB  
> container farm, an incoming request is dispatched to any container.  
> A transaction is distributed, too.
> An EJB container farm is for enterprise-level runtime performance.  
> Load-balancing enables the dispatcher to forward  an incoming  
> request to an "idle" EJB container. Fail-over enables the dispatcher  
> to detect when an EJB container is no longer responding.
> As we know, a static field is unique within a classloader and does  
> not participate in the serialization mechanism. Therefore, a static  
> field does not work across passivate/activate. Any resource that  
> must be "static" cannot be distributed. You can, and should, design  
> with these limitations in mind.
> Static fields in an EJB are not "allowed" according to the  
> specification. This rule is not enforced with an error message.  
> Rather, it is a serious warning that static fields do not work as  
> some might expect in an EJB container farm.
> Thanks,
> At 02:12 PM 6/18/2008, you wrote:
>> On Jun 18, 2008, at 1:19 AM, <> <

>>  > wrote:
>>>>> Are static fields also allowed in interceptors like I want to do  
>>>>> it?
>>>> According to the spec they are not allowed, but it is an
>>>> unenforceable and in my opinion a stupid restriction.  To my
>>>> knowledge no vendor actually stops you from using static
>>>> fields.  If you really really
>>>> want to be spec compliant, put the actual field in another class.
>>>> This is legal since EJBs are allowed to use other Java classes.
>>> So it is always the case that during the execution of a bean chain
>>> each bean stays on the same server instance? Or can it be imagined
>>> that some mechanism distributes beans to other VMs where the static
>>> information is missing?
>> In the early days, of EJB there were lots of ideas about how one  
>> could
>> build an EJB server, which led to the restrictions section in the EJB
>> spec.  One or the more unique designs came from Enhydra, which
>> envisioned a single EJB server running over a set of vms.  The idea
>> was this would make your applications scale effortlessly.  I don't
>> believe they ever finished building the system, and if they ever did,
>> I doubt it would be very efficient given the cost of an rpc vs a  
>> local
>> call.  In the end the industry settled down to a single vm design and
>> scaleability is achieved horizontally with homogeneous servers.  I
>> wish the spec committee would simply drop all of the restrictions and
>> adopt the restrictions of Servlets.
>> Anyway, I am not aware of any EJB implementations that automatically
>> start distributing beans.  A call to bean in a remote vm has such
>> different behavior compared to local bean, that EJB server can't
>> automatically start distributing beans remote VMs.  When you have a
>> truly remote call in an application, you typically need to design the
>> application with this in mind, since remote calls can fail for random
>> reasons, and local calls really only fail for a small set of known
>> problems.  As a programmer you are normally aware which beans are
>> truely Remote because they have special configurations to tell the
>> server where the bean is located, security requirements, and other  
>> rpc
>> protocol information.
>> -dain

View raw message