Thanks for the link, but my issue is dosent the session facade pattern increase the complexity of development considering the different business/session layers we need to implement it. Also, stateful beans don`t provide pooling, so if you have 1000 users on your server, you have also 1000 session beans instances running ! and if a session facade consists of more than one session beans interfacing entity beans we have n times the instances. How to solve this issue of multiple instances.... Thanks, :roll:
You can have a stateless session bean as a session facade. The link above talks about how to implement session facade as SLSB and also SFSB and compares the two approach.
Thanks for the link, but my issue is dosent the session facade pattern increase the complexity of development considering the different business/session layers we need to implement it.
Session facade does not complicare development but hides the underlying complexity from the client. The advantages are many.
Thanks for the link, but my issue is dosent the session facade pattern increase the complexity of development considering the different business/session layers we need to implement it. I think most of the design patterns add complexity to the development process. You add more layers, more services, etc (data transfer object, service locator, facades, business delegates, you name it). But when you get to the point of maintaining, improving and existing your architecture/application, then you'll see the benefits of using patterns. my $0.02
Thanks again... Ok, so patterns help in abstracting complexity and blah blah... so why is it we have to think before inplementing EJB's in our architecture, why cant we just make it a design stratgy for all our applications, instead of just few... are there overheads to the EJB approach... Regards,
Ok Pradeep... I mean, is the EJB design stratgy applicable to all kind of applications or depends on other factors such type of application, users, server, etc.? Can we use EJB for all types of intenet applications... Are there any constraints to the EJB stratgy? Regards,
If your application doesn't need the services an EJB Container provides, you could implement the same logical, easy-to-maintain structure for your application using plain old Java objects.
Can we use EJB for all types of intenet applications... hmm.. we've got to be very careful when generalizing... That's the reason we have to check/state the requirements in a proper way. Otherwise we might end up in big trouble.
Originally posted by Andres Gonzalez: Can we use EJB for all types of intenet applications... hmm.. we've got to be very careful when generalizing... That's the reason we have to check/state the requirements in a proper way. Otherwise we might end up in big trouble.
in the whole architecture. As Lasse said, there's no justification in using EJB when you can just use servlets/jsp. I think that all depends on the requirements (transactions, concurrent access, etc.)
Originally posted by Lasse Koskela: If your application doesn't need the services an EJB Container provides, you could implement the same logical, easy-to-maintain structure for your application using plain old Java objects.
Just to add to what Lasse said... for a vast majority of J2EE Applications, EJB is unecessary.
Just to add to what Lasse said... for a vast majority of J2EE Applications, EJB is unecessary.
JDO/Toplink wouyld be better bet for persistence I guess. BTW, Chris isnt it very late night for you right now? :roll: [ August 29, 2003: Message edited by: Pradeep Bhat ]
Pradeep, I havent tried this but does EJB support threads?
You are not supposed to use threads. From spec The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread; or to change a thread�s priority or name. The enterprise bean must not attempt to manage thread groups.
BTW, Chris isnt it very late night for you right now?
Pradeep, bartenders don't need sleep. We are able to refill our physical and mental batteries by means of telepathy (we have outsourced sleeping to other people).
So does this mean the EJB model may not work in a threaded environment? What if i refer a EJB class from another synchronized method of my simple java class that extends Thread class? How would the bean instance be served to multiple threads? Will there be multiple instances of the EJB or one instance would be used?
Originally posted by Pradeep Bhat: BTW, Chris isnt it very late night for you right now?
Yes, but people will go to great lengths to avoid work. Right now I am trying to avoid packing for our impending move on Saturday.
Originally posted by Lasse Koskela: Pradeep, bartenders don't need sleep. We are able to refill our physical and mental batteries by means of telepathy (we have outsourced sleeping to other people).
Originally posted by Tejpal Singh: Will there be multiple instances of the EJB or one instance would be used?
EJB Containers have the option but is not required to pool EJB instances. This is always done (in other words I have yet to see an EJB Container that doesn't) for Stateless Session Beans, Entity Beans, and Message Driven Beans. It is technically possible to pool instances of Stateful Session Beans but it doesn't make much sense and the context switch would kill performance.
It is technically possible to pool instances of Stateful Session Beans but it doesn't make much sense and the context switch would kill performance.
Doesn't pooling stateful session bean violate SFSB life cycle. When the client invokes create the Class.newInstance method gets invoked. If pooling is done the newInstance() method does not get called. My question is life cycle violation acceptable?
So does this mean the EJB model may not work in a threaded environment? What if i refer a EJB class from another synchronized method of my simple java class that extends Thread class? How would the bean instance be served to multiple threads? Will there be multiple instances of the EJB or one instance would be used?
The client can use threads, the EJB bean class can't (shouldn't). When multiple EJB stubs (on the client-side) send an invocation request to the EJB Container, the container takes care of serializing the calls or picking up enough bean instances to serve the requests. The container guarantees that only one thread is accessing a bean instance at a time. This is a different issue than the use of threads by the EJB itself. The EJB should not use threads because they can be a very limited system resource that should be left for the container to manage. A lot of people would like to see a thread pool facility in EJB 3.0, a lot of people feel that's just bundling too much into the EJB spec... We'll see if that'll happen or not.
Using JMS obviously causes some overhead when compared to "just launching a thread" but the benefit is that the client can proceed without waiting for the response. From the container's point of view, asynchronous communication is easier to "optimize for performance" as the response time is (usually) not an issue and the asynchronous processing may be scheduled for a lower priority thread.
Chris, i have an implementation where the data is submitted from a form and to a servlet... The servlet calls my session bean "X" that refers an entity "A" that persists data to the database. The servlet also calls another JMS class "Y" that calls the same session bean "X" to persist data using another entity "B" to another table. The above model works for upto 100 simultaneous submits... however if the form is programatically submitted using a java class and using the same EJB and JMS objects, the system hangs due to the long queue of JMS data and eventually the connection is refused. My other option is to conventinally submit data directly to database using a simple DAO object. So how would you recomend me to do the same with JMS and EJB?
Doesn't pooling stateful session bean violate SFSB life cycle.
That's exactly the point. The container has to implement pooling without conflicting the "logical" lifecycle. That's why the container is forced to switch context (pick a bean from pool, load the correct state from a data store, serve the request, store the state back into the data store, return bean to pool) and that's why the reference to "killing performance".
The servlet calls my session bean "X" that refers an entity "A" that persists data to the database. The servlet also calls another JMS class "Y" that calls the same session bean "X" to persist data using another entity "B" to another table. The above model works for upto 100 simultaneous submits... however if the form is programatically submitted using a java class and using the same EJB and JMS objects, the system hangs due to the long queue of JMS data and eventually the connection is refused. ... So how would you recomend me to do the same with JMS and EJB?
Aren't you already using JMS and EJB? Or did you refer to something else than Entity Beans with "entity"? The fact that the too long JMS queue makes your system hang is something that simply should not happen. How long does the JMS queue get and how many MDBs do you have processing those messages (what's the pool size you configured for the MDB)?
My other option is to conventinally submit data directly to database using a simple DAO object.
If this works, by all means do it like this. This would be the more simple way and thus preferable over the more complex, although more scalable, asynchronous model. Also, whether it matters when the data ends up into the database affects the choice of implementation approach between synchronous and asynchronous.
Aren't you already using JMS and EJB? Or did you refer to something else than Entity Beans with "entity"? The fact that the too long JMS queue makes your system hang is something that simply should not happen. How long does the JMS queue get and how many MDBs do you have processing those messages (what's the pool size you configured for the MDB)?
entity = A Entity Bean. I am not sure of the pool size, its the default!! I have one TopicPublisher JMS bean that publishes a message. Mostly the simultaneous JMS messages do not exceed 100 mark but for certain cases the data to be submitted is very large, in that case the JMS messages sent are upto 800-900. The problem occurs then... The server log shows rigorous activation and passivation and then the socket exception and connection not found. Most probably it is the available memory/pool size issue.... the process works fine using conventional DAO objects... Just thought if can make it work with the existing JMS and EJB objects too...
Just to add to what Lasse said... for a vast majority of J2EE Applications, EJB is unecessary.
Chris, I have never used EJBs and was considering building them into the application I work on, do you think I shouldn't because we have not felt any need for doing so. How can I determine whether I would need EJB for an app - is it matter of experience in architecting. Thanks.
Chris, I have never used EJBs and was considering building them into the application I work on, do you think I shouldn't because we have not felt any need for doing so. How can I determine whether I would need EJB for an app - is it matter of experience in architecting. Thanks.