Transaction Problem in Session Facade Design Pattern

Hi
Well Sorry for giving wrang title to the topic, coz of which I have not received and reply.
I am using session facade design pattern.
I have Action class calling session facade method "getData" . This method calls "findByPrimaryKey" method in BMP.
Method "getData" has transaction attribute as "RequiresNew" and "findByPrimaryKey" has "Required".
This combination does not assign identity to BMP hence I can not use setter getter method for retriving data(throws nullpointer exception when getter method accessed) I have made sure that I am accessing table and getting data in to BMP but as BMP is not ablle to hoild any identity its not allowing me to use BMP's getter method in session facade.
I have Used Same transaction attribute for create method called by "addNew" method of session facade bean.
Transaction method for "addNew" is "RequiresNew" and for "create" is "Required".
It works fine and gives identity toBMP hense I can use Setter getter method defined in BMP bean.
How can I avoid this and get BMP an identity?
Thanking in Advance,
Chintan.

Sorry, how is this related to JSF?
There's an OO/patterns forum out. Consider reposting the question over there with formatted code.

Similar Messages

Business delegate and Session facade design patterns

Does any one tell me, what is the difference between business delegate and session facade design patterns.

1. Session Facade decouples client code from Entity beans introducing session bean as a middle layer while Business Delegate decouples client code from EJB layer ( Session beans).
2. SF reduces network overhead while BD reduces maintenance overhead.
3. In SF any change in Session bean would make client code change.
While in DB client is totally separate from Session bean because BD layer insulate client from Session beans(EJB layer).
3. In only SF scenario, Client coder has to know about EJB programming but BD pattern no EJB specialization needed.
4.SF emphasizes on separation of Verb, Noun scenario while BD emphasizes on separation of client(presentable) and EJB layer.
Anybody pls suggest more differences ?

What is meant by session Facade design pattern

please give me

cripes
http://www.google.com/search?q=what+is+meant+by+session+Facade+design+pattern
Who'd have thought it? ;-)
kind regards,
Jos

Traction Problem In Session Facade Disign

Hi
I am using session facade design pattern.
I have Action class calling session facade method "getData" . This method calls "findByPrimaryKey" method in BMP.
Method "getData" has transaction attribute as "RequiresNew" and "findByPrimaryKey" has "Required".
This combination does not assign identity to BMP hence I can not use setter getter method for retriving data(throws nullpointer exception when getter method accessed) I have made sure that I am accessing table and getting data in to BMP but as BMP is not ablle to hoild any identity its not allowing me to use BMP's getter method in session facade.
I have Used Same transaction attribute for create method called by "addNew" method of session facade bean.
Transaction method for "addNew" is "RequiresNew" and for "create" is "Required".
It works fine and gives identity toBMP hense I can use Setter getter method defined in BMP bean.
How can I avoid this and get BMP an identity?
Thanking in Advance,
Chintan.

Hi
I am using session facade design pattern.
I have Action class calling session facade method "getData" . This method calls "findByPrimaryKey" method in BMP.
Method "getData" has transaction attribute as "RequiresNew" and "findByPrimaryKey" has "Required".
This combination does not assign identity to BMP hence I can not use setter getter method for retriving data(throws nullpointer exception when getter method accessed) I have made sure that I am accessing table and getting data in to BMP but as BMP is not ablle to hoild any identity its not allowing me to use BMP's getter method in session facade.
I have Used Same transaction attribute for create method called by "addNew" method of session facade bean.
Transaction method for "addNew" is "RequiresNew" and for "create" is "Required".
It works fine and gives identity toBMP hense I can use Setter getter method defined in BMP bean.
How can I avoid this and get BMP an identity?
Thanking in Advance,
Chintan.

Facade design pattern example?

Can someone point me to a LabVIEW example of this OOP design? I am learning OOP in LabVIEW and my task is to create an example program using the facade design pattern. I can't find an example to study.
Solved!
Go to Solution.

I'm interested, too, so I posted a link to your question on LAVA. There are a lot of discussions of this sort over there.
Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice

Session Facade design and TopLink objects

Hi, we are just about to start using Toplink as our ORM tool. Ideally we want to wrap all business logic behind stateless session bean facades. So instead of BMP entity beans we are thinking of encapsulating the relevant Toplink objects in each facade and querying, updating that object when the session facade bean is instantiated.
We are using Weblogic 70. Example code:
e.g. MySessionBean implements sessionbean...
     MyTopLinkObject myObject = null;
     public void populateObject(String myID) throws java.rmi.RemoteException {
          try {
               MyTopLinkObject myObject = new MyTopLinkObject(myID);
          catch (Exception e) {
     public void setMyTopLinkObjectsName(String name) {
     //persist this change via the toplink object...
     myObject.setName(name);
Then in MyTopLinkObject:
public class MyTopLinkObject {
     private String myID;
     private String myName;
public MyTopLinkObject(String myID) {
          build(myID);
public void build(String myID) {
          //read TOPLINK cache and populate this MyTopLinkObject name etc
public void setName(String myName) {
     //persist this change...
     this.myName = myName;
// more gets sets
I will then want to update MyTopLinkObject data in for example in calling. MySessionBean.setMyTopLinkObjectsName("my name") from the remote interface on the client.
So what I want to know is how do I can I do this efficiently. I'm too too versant with TopLink caches etc. For example to read the cache do I have to pass thru a TopLink client/server Session to each Session Facade bean so the cache is available for that read, update etc?
Any other tips is using this design would be appreciated!
Thanks in advance,
J

Don, thanks for ur advice yet again.
I think now I am getting a better grasp of how TopLink should be used. However there is very little doco out there in terms of using TOPLInk in as EJB session facade scenario.
After your advice my thoughts are to provide something like the TOPLInkFactory object as you say which will encapsulate the ServerSession TOPLink API and provide more fine grain access to the TOPLInk API. e.g. instead of having to create a ClientSession in each client call b4 getting a UnitOfWOrk, this factory class would provide a method to do this directly:
public final class TOPLinkFactory {
     private static ServerSession serverSession = null;
     private static final String TOPLINK_CONFIG_FILE = "C:\\test.xml";
     private static final String TOPLINK_SESSION = "toplink";
     public TOPLinkFactory() throws Exception {
          super();
     private static ServerSession createServerSession(ClassLoader cl) throws Exception {
          try {
          Project builderProject = XMLProjectReader.read(TOPLINK_CONFIG_FILE, cl);
     serverSession = (ServerSession)builderProject.createServerSession();
          serverSession.login();
               return serverSession;
          catch (Exception e) {
          return null;
     public static UnitOfWork getUnitOfWork(ClassLoader cl) {
          try {
               return createClientSession(cl).acquireUnitOfWork();
     public static ClientSession createClientSession(ClassLoader cl) throws Exception {
          try {
               if (serverSession == null) {
serverSession = createServerSession(cl);
ServerSession s = (ServerSession)SessionManager.getManager().getSession(TOPLINK_SESSION, cl);
               return serverSession.acquireClientSession();
          catch (Exception e) {
          return null;
Then in my Session EJBs I could write a method like this where Thing is a TOPLInk object mapped to the thing table:
     public boolean setThingStatus(String thingID) {
ExpressionBuilder builder = new ExpressionBuilder();
Expression expression = builder.get("THING_ID").equal( Integer.parseInt(thingID));
ClientSession s = TOPLinkFactory.createClientSession(this.getClass().getClassLoader());
Thing thing = (Thing) s.readObject(Thing.class, expression);
UnitOfWork uow = TOPLinkFactory.getUnitOfWork(this.getClass().getClassLoader());
Thing thingClone = (Thing)uow.registerObject(thing);
thingClone.setStatus("WITH JASON");
TOPLinkFactory.commitAndReleaseUnitOfWork(uow);
return true;
Now if the above looks OK and there are no Thread/Session issues that you could make me aware of (or perhaps you would encourage using a full Singleton pattern instead).
I have another question in relation to ClassLoaders. In this architecture I have been passing around the ClassLoader (as above) to the TOPLInkFactory methods to create the unit of works etc... Is this necessary? Or could I avoid it?
Also I think some people in my team are thinking its a good idea for all TOPLink business objects to extend an abstract base class that contains this behaviour and provides these TOPLinkFactory methods. I no expert on TOPLInk but I would have thought this code should not be coupled with the TOPLink business objects for reasons such as:
1) Why should a TOPLink Person object (attributes name, age etc) e.g. extend a class with TOPLink API methods and attributes - I just don't see the logic there as I thought TOPLink was to be non-intrusive. For example a Person object should not encapsulate a ServerSession object and nor does it need to. To this end they are then coupled and if for example we wanted to move these Person objects to work with another persistence framework then they would have to be rewritten to remove all TOPLInk attribute/method references
2) I would have thought accessing the TOPLInk API is only necessary when the client code needs to invoke calls to the database for reads and updates. i.e. that's where you start getting your sessions, unit of works etc. Like in the setThingStatus Session EJB method (i.e. the client code) above and NOT in your business methods of for example the TOPLink Person object?
Please tell me if I am mistaken!
If you could clear some of this up it would be great.
Regards,
Jason

Factory v/s Facade Design Pattern.

Folks,
I was just going thru the Design Patterns (Factory Pattern and the
Facade Pattern)
The Factory Pattern :
The factory completely abstracts the creation and initialization of the product from the client
This indirection enables the client to focus on its discrete role in the application without concerning itself with the details of how the product is created. Thus, as the product implementation changes over time, the client remains unchanged.
Client--------------------->Factory----------------->Product
The Facade Pattern
Encapsulate the subsystem using a High-Level Interface/provides a
simplified and uniform interface to a large subsytem of classes.
The Client communicates with the 'Facade' which has methods to interact
with subsystems.The Client very rarely accesses objects in the subsystems.
Subsystems objects usually retain no knowledge of the client.
Subsystem objects do not normally maintain any reference to Fa�ade.
Client------------------->Facade------->Subsystems
My Question is this:
Arent both these pattern quite similar becos both designs access an Interface
which inturn invokes the required object of the subsystems?
Can anyone explain the major difference?

Perhaps these definitions will clarify things a little for ya...
Fa�ade
The Fa�ade pattern simplifies access to a related set of objects by providing one object that all objects outside the set use to communicate
with the set. This also promotes a weak coupling between the subsystem and its clients. This weak coupling allows you to vary the
components of the subsystem without affecting the clients.
Factory
Centralize the assembly of resources necessary to create an object. This prevents the need to change all classes from changing when a
Product changes and makes any change needed occur only in the Factory.

Business Delegate and Session Facade usage.

Hi guys.
I am new to JavaEE and I recently learnt the Business Delegate and Session Facade design patterns. The tutorials from Oracle did gave me a basic idea of what they are and why they are used, but the example didn't really answer all my questions. So I decided to use a real life scenario here and put my question in to it. Any help is appreciated.
Assume I want to create a search employee page for my company, the employees are categorized by his or her department and the province he or she is in. I have in the database a look up table for department and province. (as shown in the image below)
http://oi46.tinypic.com/idvpsl.jpg
So I create three JPA entities, one for each table. Now I am stuck with what is the proper way to design the session facade design pattern. I know that I will need the to access all three entities in my page. (to get the drop down list for Provinces and Departments, and to retrieve list of Employees based on the selection) So should I create a Stateless Session Bean as session facade to access all three JPA Entities or should I create three separate Stateless Session Bean to manage one Entity each?
I came up three component diagram in the below picture.
The first one has one Stateless Session Bean as session facade and manages all three Entities.
The second one has a session facade to manage the relationship between business objects such as ProvinceManagerEJB and DepartmentManagerEJB which will manage the corresponding Entities.
The last one has three Stateless Session Beans that will manage one Entity each, all three Stateless Session Beans can be looked up via the Business Delegate pattern.
http://oi46.tinypic.com/10pqets.jpg
Please let me know if any one of them is the proper way to use business delegate and session facade. or none of them is correct. (which I assume might happen)
Again, thank you so much for your help.
Cheers
Edited by: 992005 on 05-Mar-2013 18:15
Edited by: 992005 on 05-Mar-2013 18:17

Well I can't access any of your diagrams from here so can't comment on them. For dividing the functionality into separate classes, think about
1.) Quantity - Are there many enough service calls to require splitting up or will one application service class be enough? The size of the system is important here.
2.) Are you duplicating logic in the services? e.g save person, delete person in one service and save department, delete department in another e.t.c is better factored into one service with save entity, delete entity calls because the JPA entity manager doesn't know about the type anyway and it's easier to apply common logic (e.g logging auditing) around the calls.
3.) Will each service makes sense on it's own or do you always need the other functionality to completely describe the service? Here it is important not think about entities but about the business use cases. Process1Service is better than Entity1Service, Entity2Service ... EntitynService.Think granule of reuse = granule of release. Only split out individually reusable services. A good way to understand granules of reuse in your system is to think about (or start by writing) test cases for the functionality. Testable code is reusable code.
4.) Will the services change together? At class level you would look at common closure principle (classes that change together should be packaged together). You can apply the closure to the methods as well. Make it easy for future developers to recognize dependent functionality by packaging it together.
These are just general because in enterprise development requirements are king. You can chose to follow or discard any of these rules depending on your requirements as long you understand the impact of each decision.

Facade and Session Facade

All,
Well this is the closet forum i could get to post my question so please excuse me if it is in wrong place.
Can anyone mention the types of facade design pattern available ? Also what is the diff between Facade and Session Facade ?
PS : My application is getting developed in ADF :)
thnks

in the line of fire wrote:
All,
Well this is the closet forum i could get to post my question so please excuse me if it is in wrong place.
Can anyone mention the types of facade design pattern available ? Also what is the diff between Facade and Session Facade ?This is no really ADF specific. You may wish to consult both the "Gang of Four" book along with Fowler's "Patterns of Enterprise Architecture."
A quick answer: the Facade pattern defines an object ( or method on an object) that executes a workflow involving other objects that you wish to hide from client applications or objects.
A session facade is the same idea applied to JEE session beans, where a single call to a session bean may include interacting with other beans, entities, databases, etc.
Hope that helps,
Chad
>
PS : My application is getting developed in ADF :)
thnks

JDBC Design Patterns

Hi All,
I am new to patterns and have started understanding them using the Head First Series.
I would like to know what all design patterns are there in JDBC?
Can i say that JDBC uses a Facade design patterns as it hides the database specific details and provides us a interface which helps us to connect to a database. What other design patterns exist as part of the JDBC?
Request you to clarify my doubts.
Many thanks in advance

I would really appreciate a good discussion on it
rather than any spoon feeding.
A typical JDBC code will appear as follows:
try
/* Load the jdbc-odbc driver
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
// Open a connection to data source
con
=DriverManager.getConnection("jdbc:odbc:DBName","","")
// Get a statement from the connection
Statement stmt = conn.createStatement() ;
// Execute the query
ResultSet rs = stmt.executeQuery( "select * from
table_name" ) ;
1. Is it ok to look into each statement of the above
code snippet in terms of Design Patterns.it's ok, yes. not necessarily appropriate or worthwhile, though
2. How can one dissect each line of the code in terms
of various design patterns?you can't. design patterns exist at a higher level of abstraction than code. 'in terms of' is also disconcertingly vague.
3. Is it correct to conclude that java.sql package
overall uses Abstract Factory Pattern.
As it uses lot of interfaces and implemetation is
provided by the Vendors. yep. that sounds fair enough. not very useful, though
4. Consider a particular package like
java.sql.Statement,java.sql.Blob,java.sql.Connection
etc. is is correct to conclude that
its an example of a Factory Method Pattern as any
client would instantiate. Here the client would be
Statement object,
Creator is Connection Interface and createStatement()
is the factory method.possibly. there's little value in trying to define everything as a "design pattern", though. rather than thinking "oh, they must be using PATTERN X here", think "if I were writing this code, I think PATTERN X would be appropriate". or, more usefully, "is there a pattern that solves this problem?". there isn't, necessarily
5. I am not able to understand if a statement like
Class.forName() should be viewed only in terms of a
programming instruction or
any design patternit's a line of code, nothing more. stop trying to make everything into a pattern. until you realise where patterns are and aren't applicable, you'll never understand them
6. Can "stmt.executeQuery()" can be viewed as A
Strategy Pattern? nope. what makes you think that?
I would really welcome a good discussion on the above
questions.does the discussion have to involve design patterns? you know, of course, that design patterns aren't magic beans, right? I know you've just discovered patterns, and are all excited by them, but seriously, they're only ideas, not Infallible Solutions To All Software Problems ™. the most common mistake people make using design patterns is to see them everywhere, and try to bend every problem to fit a particular pattern
for the record, nobody really views JDBC in terms of patterns. there's little value in viewing existing technologies in those terms, since the most you can "gain" is to have guessed what some other developer did, before.

SERVICE LOCATOR ?? Is it really an interesting Design pattern??

Hi everybody,
i've a problem with the J2EE Design Pattern "Services locator" (it's a singleton).
It is said that by making use of a Service Locator we can :
- hide to the client the complexities of initial context creation, EJB home object lookup,and EJB objectre-creation.
- multiple clients can reuse the Service Locator object to reduce code complexity, provide a single point of control, and improve performance by providing a caching facility.
But i would like to understand at which side should that service locator object reside??!!??
If it is at server side then the clients need well an initial context in order to make a lookup on that object.
Conclusion :
the service locator doesn't hide the complexities of initial context!!
Furthermore the client has to perform a look-up on that service locator object!! The only advantage left is caching facility.
If it is at client side, each client needs his own services locator object
Conclusion :
multiple client don't reuse the same service locator. What's the advantage to be a singleton ???
There is certainly something that i don't understand so help me please!! Thanks.

Hi Yves,
But i would like to understand at which side should
that service locator object reside??!!??
If it is at client side, each client needs his own
services locator object
Conclusion :
multiple client don't reuse the same service locator.
What's the advantage to be a singleton ???The service locator resides on the client side and is implemented as
a singleton. Since it is possible that there could be multiple
class loaders/JVMs on the client side, and therefore, multiple
instances of the "singleton" service locator. This is typical
in a distributed environment (e.g. servlets/JSPs in a web-tier
cluster using service locator). Thus service locator is not
a truly "distributed singleton" object. But, the empahsis
is to design the service locator such that it does not hold
any state that needs to be replicated across multiple
instances across different JVMs as mentioned. Thus, there
is no need for multiple clients to use the "same" service locator,
but still the benefits of implementing this pattern is realized.
By making it a singleton, and keeping it from holding state
that needs to be replicated, we realize the benefits of this pattern.
You may also want to visit the J2EE Pattern interest list
and see these relevant discussions :
Topic: Service Locator and passivation
http://archives.java.sun.com/cgi-bin/wa?A2=ind0106&L=j2eepatterns-interest&F=&S=&P=1026
Topic: Caching EJBHome interfaces
http://archives.java.sun.com/cgi-bin/wa?A2=ind0106&L=j2eepatterns-interest&F=&S=&P=9226
Topic: Using Service Locator for Data Source caching
http://archives.java.sun.com/cgi-bin/wa?A1=ind0106&L=j2eepatterns-interest#31
hope this helps,
thanks,
-deepak

Any Design Patterns for rendering stuff?

Hi everyone,
I was wondering if there is a design pattern available that can be used to render different types of stuff. My dad is not of one type, it is dynamic, so how can I render it?
Thanks

hi, thanks for your reply.
basically, I want to be able to render something where the first row contains two columns, and the next row contains one big image.
Like the following:
|............................................|...........................................................................|
|............................................|...........................................................................|
|............................................|...........................................................................|
|___________________|________________________________|
|........................................................................................................................|
|........................................................................................................................|
|........................................................................................................................|
|........................................................................................................................|
|........................................................................................................................|
|........................................................................................................................|
|........................................................................................................................|
|........................................................................................................................|
|........................................................................................................................|
|___________________________________________________|
The problem is that an image will not always be produced.
If the image is not produced, then I only want one row.
If it is produced, then suppose then I want the two rows to be equal in length.
I just do not know how to approach this problem.
Will the design patterns you mentioned help with this problem?
Thanks.

Session Facades

A question on session Facade design:
Assume two front end banking applications both needed to perform a Withdrawal on a bank account.
Also Assume that the coarse grained Withdrawal method would perform a set of fine grained methods (which were currently the same for the two applications but could potentially be different at some point in the future)
Should the Withdrawal method be duplicated in two different facades (one per application) or should it be in a common facade that they both used.

You're right when you're saying that you shouldn' have a fa�ade for every table.
A facade is business-driver where an entity is data driven.
You should try to group the methods in Fa�ades by "themes" rather than data. In other words, to group methods that have similare purposes, rather than thinking in terms of data.
Knowing that, it is hard to tell what size your fa�ades should be. To big, you might have performance issues, to small, they'll become unmanageable.
Ours are usually 10-methods big average. Theses methods being quite high-level.
Stephane

Difference between Session Facade and Business Delegate design patterns

Can someone tell me the differences between Session Facade and Business Delegate design patterns

1. Session Facade decouples client code from Entity beans introducing session bean as a middle layer while Business Delegate decouples client code from EJB layer ( Session beans).
2. SF reduces network overhead while BD reduces maintenance overhead.
3. In SF any change in Session bean would make client code change.
While in DB client is totally separate from Session bean because BD layer insulate client from Session beans(EJB layer).
3. In only SF scenario, Client coder has to know about EJB programming but BD pattern no EJB specialization needed.
4.SF emphasizes on separation of Verb, Noun scenario while BD emphasizes on separation of client(presentable) and EJB layer.
Anybody pls suggest more differences ?

Business Delegate and Session Facade Pattern

Hi!
The only way to use the Session Facade Pattern, is if I use EJB for Persistence.
Is valid to do this?:
I use Ejb for simple update, insert querys. From my business delegate I call the Session Facade Layer, and from this I invoque Entyties for persistence.
But if I have complex querys, is correct to make PL SQL Procedures and do the following:
From my business delegate I call to the Dao layer, and from this via JDBC I call the Procedure.
Please explain me the best form to do this, having complex querys for reporting and simple querys for inserts/update.
Is valid to combine the use of CMP (for simple persistence cases), BMP (for complex persistence cases), and JDBC for complex select querys with multiple result rows.
Thanks!!

It depends on your design goals. One of the forces driving the use of patterns is the desire to tier an application and abstract the internals of each tier away from the other tiers. One (normal) benefit of this methodology is that the application should become more portable. Now, if you are using PL/SQL, BMP and CMP, you are mixing and matching portable versus proprietary. This is okay. But you should abstract away whether you are using PL/SQL, BMP or CMP from the business layer (or domain model). Ideally, you could completely swap database technologies (say from relational to object) and only have to re-write your integration tier (your DAO's).
Session facade is simply a glorified Facade pattern. It abstracts the lower-level details of what you are persisting and instead forces you to think in terms of objects. You can use a facade without even remotely touching EJB's. It just so happens that, historically, EJB containers made a mess out of scalability when it came to entity beans. The "session" facade refers to a facade pattern implemented in session beans (that have fewer scalability problems) communicating with the entity beans which do have scalability problems.
So... to make a long story short, use whatever persistence mechanism you desire. Remember that you should be able to completely switch your persistent store from one type or another and simply re-write your DAO's (or CMP deployment descriptors). Using a facade pattern can help towards this end, but don't make it a straightjacket.
- Saish
"My karma ran over your dogma." - Anon

Transaction Problem in Session Facade Design Pattern

Similar Messages

Maybe you are looking for