Alex Averbuch

Greenhorn
+ Follow
since Apr 16, 2012
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alex Averbuch

I posted in two places to reach a wider audience, as some members of Code Ranch may not be active on Stack Overflow
Hi,
I have three questions:

(1)
According to this link (Using Hibernate with Tomcat) running Hibernate in Tomcat is possible (despite the fact Tomcat does't support JPA).
Does anyone know if I'll run into problems with this configuration?

(2)
Can I do something similar to get EJB3.1 support in Tomcat?
For example, if I drop the correct files into WEB-INF/lib and WEB-INF/classes will it be possible to run EJB3.1 in a standard Tomcat7 container (not TomEE)?
If it is possible, which EJB3.1 provider is recommended?

(3)
Generally, is it possible to run any JavaEE technology from within Tomcat as long as I place the appropriate libraries and configuration files in WEB-INF/lib and WEB-INF/classes?
Or, is it only possible to run the technologies for which Tomcat supports the interfaces?
And, lastly, If it's not possible, then why does Hibernate work?

Thanks in advance for all help!
Thanks again Tim,
If/when I have more questions I'll get back to you!
11 years ago
JSF

Tim Holloway wrote:Probably the easiest way to provide high reliability is to employ shared sessions. That is, the HttpSession object is replicated automatically between server instances.
[...]
JSF state saving and HTTPSessions are 2 different things, so each part of the equation has to be dealt with separately. You still need session-scope objects when using stateful Model components (such as DataModel). View Scope is merely Session Scope with automatic removal. The JSF state is independent of that, and it manages the JSF component tree.


OK, this is new to me!
If I get you right...
  • JSF component tree = all of (and only) the view-related state, i.e. the text to place in outputLabel, etc.
  • HttpSession = cached model-related state. does that mean backing bean state is stored in HttpSession?
  • 11 years ago
    JSF
    Hi Tim, thanks for the detailed reply.
    Regarding your comments, I have a few questions, but I'm new to enterprise Java, so please bare with me...

    Tim Holloway wrote:JSF itself has no interest in clustering technologies. It leaves all that up to the webapp server itself, so the options and settings are entirely done at the server level and JSF code is clean. So your options are basically whatever options the server provides.


    OK, but what is the common way for JSF developers to horizontally scale their applications?
    For example, if a server technology provides the clustering ability, how does it know what state to replicate?
    And, how would a developer specify that the component tree (for example) needs to be replicated?

    Tim Holloway wrote:You can, however, make the state be client-side rather than server-side. That's a basic configuration setting for JSF webapps done in web.xml. The caveats are that because the state is shipped to/from the client, it's extra network overhead, and somewhat less secure than if the information never left the server, but the advantage is a lot less continuous memory usage on the server.


    I guess you mean this setting:

    And perhaps this to reduce the amount of data being sent around:

    Using these two settings, will the application be truly stateless (i.e. any server in the cluster can serve any incoming request)?
    If not, what state remains?

    Thanks again,
    Alex
    11 years ago
    JSF
    Given that JavaServer Faces is inherently stateful on the server side, what methods are recommended for horizontally scaling a JSF 2.0 application?

    If an application runs multiple JSF servers, I can imagine the following scenarios:

  • Sticky Sessions: send all requests matching a given session to the same server.
    Question: what technology is commonly used to achieve this?
    Problem: server failure results in lost sessions... and generally seems like fragile architecture, especially when starting fresh (not trying to scale an existing application)


  • State (Session) Replication: replicate JSF state on all JSF servers in cluster
    Question: what technology is commonly used to achieve this?
    Problem: does not scale. total memory of cluster = total memory on smallest server


  • Instruct JSF (via configuration) to store its state on an external resource (e.g. another server running a very fast in-memory database), then access that resource from the JSF servers when application state is needed?
    Question: is this possible?


  • Instruct JSF (via configuration) to be stateless?
    Question: is this possible?
  • 11 years ago
    JSF