Forums Register Login

Session Facade

+Pie Number of slices to send: Send
Hi all,
I want to know the significance of session facade and when to and when not to session facade.
Thanks in advance!!
+Pie Number of slices to send: Send
+Pie Number of slices to send: Send
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:
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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,
+Pie Number of slices to send: Send
 

are there overheads to the EJB approach...


Come again. Sorry I did not get you.
+Pie Number of slices to send: Send
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,
+Pie Number of slices to send: Send
 

Can we use EJB for all types of intenet applications...


Yes. Is there any specific you feel that it may not work?
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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.


Where do you think the trouble will be?
+Pie Number of slices to send: Send
 

Originally posted by Pradeep Bhat:

Where do you think the trouble will be?


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.)
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
BTW, you're also right:
Can we use EJB for all types of intenet applications...
Of course we can, I just wanted to point out the consequences.
+Pie Number of slices to send: Send
 

Originally posted by Chris Mathews:

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 ]
+Pie Number of slices to send: Send
Message accidentally edited by the bumbling bartender. Sorry.
[ August 29, 2003: Message edited by: Chris Mathews ]
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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).
+Pie Number of slices to send: Send
 

Originally posted by Tejpal Singh:
Pradeep, I havent tried this but does EJB support threads?


See this thread.
+Pie Number of slices to send: Send
 

Originally posted by Pradeep Bhat:

You are not supposed to use threads.


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?
+Pie Number of slices to send: Send
 

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).


Shh... you've said too much.
+Pie Number of slices to send: Send
Suppose I use threads in EJB class is the container going to throw RuntimeException.
I have never used it so the question ?

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.
quote:


Saturday.. are you from Australia?
Lasse, I know it is morning for you.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

Originally posted by Pradeep Bhat:
Saturday.. are you from Australia? Lasse, I know it is morning for you.


No I'm in the US, so Saturday is still two days away... there is just a lot of stuff to pack.
+Pie Number of slices to send: Send
 

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?
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

From the thread:

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?
+Pie Number of slices to send: Send
 

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".
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

Originally posted by Lasse Koskela:

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...
+Pie Number of slices to send: Send
I think you should search the appserver-specific forums for a resolution (this sounds like a configuration issue).
+Pie Number of slices to send: Send
Maybe your right Lasse, it is the configuration issue...
Thanks...
dont you guys ever sleep...
+Pie Number of slices to send: Send
You can post the problem in app server specific forum.

Thanks...
dont you guys ever sleep...


Lasse and Chris do not sleep so that other java ranchers can have a nice sleep.
+Pie Number of slices to send: Send
Keep it up...
Anyways cant have a good sleep in software business...

there are always issues to resolve...
Cheers!
+Pie Number of slices to send: Send
 

Originally posted by Chris Mathews:

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.
+Pie Number of slices to send: Send
Requirements and resources available can help you to decide.
Read this intresting artcile
http://www.theserverside.com/resources/article.jsp?l=Is-EJB-Appropriate

Originally posted by Faisal Khan:

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.

 
+Pie Number of slices to send: Send
Hi All,
In responding to Maria in the OO, Patterns, UML forum I touched on some related topics, so I thought you might be interested.
Here's a link to the thread
https://coderanch.com/t/98414/patterns/bean-or-not-bean)
Thanks.
+Pie Number of slices to send: Send
The correct URL for Dan's reply (see above) is:
https://coderanch.com/t/98414/patterns/bean-or-not-bean
Whip out those weird instruments of science and probe away! I think it's a tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 1471 times.
Similar Threads
business delegate
session facade and message facade
J2EE patterns
Confused in Design Patterns
limit the no of sessions with struts.
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
BD-SLSB-SFSB
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 18, 2024 20:31:18.