Win a copy of Micro Frontends in Action this week in the Server-Side JavaScript and NodeJS forum!

Phil Sharp

Ranch Hand
+ Follow
since Nov 08, 2001
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Phil Sharp

Looks like you are implementing the Service Locator J2EE pattern. You might want to look up the following reference:
Its in the restricted area so if the above does not work try
then go to the Service Locator link.
Its also in the Core J2EE patterns book. Unfortunately it only mentions caching as a posibility at the end with no details on best approaches.
One thought if you continue using your bespoke method you will need to catch exceptions for any home timeouts\failures that may occur at the Weblogic side. Although shouldn't be too difficult to handle.
[ May 03, 2002: Message edited by: Phil Sharp ]
I think you are probably best leaving it to your application server to handle caching.
Application servers themselves are caching EJBs to provide the best performance they can. Look at your application server documentation to find out about its caching method\policy.
As a general point I would not do any performance improvements until I had a working system and a performance problem was diagnosed. The don't fix it if its not broken approach. Generally making optimisations tends to obscure the code and so make it more difficult to support.
If there is a problem then its important to do analysis to find exactly where the bottlenecks. are. I doubt if caching home interfaces will have much effect on the system performance.
Not sure anyway if your plan to cache home interfaces is good anyway, you cannot be sure of the object that is backing the interface as that is application server specific and the application server may be doing something under the covers that makes cachg inappropriate.
In my opinion the best approach is to hold resources for as short a time as possible and rely on the application server to handle caching as it tends to better at it than any code I can write.
Sorry to be such a downer on your idea. Please tell me if you implement it and it has a performance impact as I'm always keen to learn new patterns.
[ May 03, 2002: Message edited by: Phil Sharp ]
[ May 03, 2002: Message edited by: Phil Sharp ]
The two books on EJBs that I'd recommend are:
Mastering EJBs by Ed Roman (pdf can be downloaded free from
and Enterprise Java Beans by Richard Monson-Haefel.
Neither are directly linked to a free J2EE server implementation unfortunately.
Enterprise Java Beans has free workbooks that you can download. They are very good unfortunately currently there are only workbooks for Weblogic and Websphere hopefully others will appear soon.
With JBoss you can get documentation (both free and for a $10 charge) which provides instructions to follow on creating EJBs amongst other things. Probably a good place to start.
Hope that gives you some ideas
As Tim states the persistence mechanism and the fact that it is local or remote interfaces does not matter.
I think you are trying to ask about concurrency.
For Session beans both Stateful and sateless its not an issue as they are logically specific to a session (note the implementation may be sharing instances but the client is not effected by this).
For entity beans the story is a little more complicated. There is only one entity bean instance for a specific entity defined by its primary key. However multiple clients can be connected to it through the EJB Object.
EJB solves the problem of concurrency by prohibiting concurrent access to bean instances. Therefore even though multiple clients can be connected to the EJB object only one can invoke methods on the entity bean instance. Any other client has to wait until a method invocation is complete. In fact the scope is larger in that a bean cannot be accessed by anything outside the current transactional context until the transaction is completed.
This is described better in Enterprise JavaBeans by Richard Monson-Haefel. A very useful resource (alongside Mastering EJBs by Ed Roman).
Some implementations such as WLS have additional functionality to improve performance - read-only beans etc. to cause further confusion - you need to review your application servers documentation for further information.
Don't really understand how you are expecting this XML field to work, don't think it can be Static as the field is instance specific?
Do you only want to use it as a performance cache? If so I'd test whether it is required before attempting it.
Would it not be easier to just have a method that returns the xml or alternatively a generic session bean that you could pass an entity bean to and it would return the xml.
I also expect people have already done this sort of thing before I'd do a trawl of the web\newsgroups to see if you can find anything. Also check out web services and SOAP interfaces for EJBs as that is creating an XML interface.
There are no problems having non-persistent field in an entity bean. If you are using BMP then you are in charge of persistence anyway, if you use CMP don't list it in the CMP fields in the descriptor. However you need to be careful, especially concerning passivate\activate.
Sorry for the confusion around synchronous. Valentin has explained my meaning far better than I could.
Hopefully everything is clear now.
Yes, a method can be overridden and you can add final, synchronized, native or strictfp.
Note it is not possible to create an abstract method that is final, synchronized, native or strictfp. This is fairly obvious as it would not make sense to do so.
Calling finalize directly is just like calling any method and will occur synchronously.
Although its probably a bad idea to call finalize directly as thats not what its there for. finalize is used to cleanup and release resources when a instance is released. finalize will get called at some point between when the last reference releases the instance and when the instance is garbage collected.
System.runFinalization() provides a hint to the JVM that it should run any outstanding finalize methods for the released instances awaiting garbage collection. Note there is no way to know which instances finalize will be called or if in fact any are. This is analigous (big word dodgy spelling) to calling System.gc
Look in the JLS section 12.6 for further information.
Try looking in config.xml, the configuration file for the server
Probably depends upon your application, its reliability\performance requirements and the rest of your solution.
Ideally you would probably want to store presentation state in the HttpSession and business state in an EJB.
Following is a link to a discussion where the issues were aired far more knowledgeably than I can do:
Hope it helps
I think your analysis is probably correct however I do not think it has to be that way.
Part of EJBs\application servers power is that they can handle distributed transactions - ie transactions that involve more than one database and so necessarily more than connection would be required in the transaction to facitalitate this. One thing to note is that you would need to use an XA driver.
I have never tried doing this so would be interested to find out if it works.
Have to say your solution of passing the connection is probably the way to go.
Finally some questions of my own which I would appreciate any knowledgeable person answering. Are multiple transactions happening here? My analysis is that if each DAO is creating a new connection (I know it is not really but from the point of view of the application it is I think) then the transaction can only have a lifetime while the connection is instantiated therefore two transactions must be occuring with the first one by default being committed. This is presumably separate from a transaction controlled by the application server?
More questions than answers I think, oh well hopefully somebody else can be more helpful.
Oddly enough just been looking at how to do finders.
Basically you need to put the finder 'SQL' in the jaws.xml, the jBoss specific descriptor file.
Following reference explains how to do it:
Looking at version 2.4.4, it appears it is only 1.1 compliant with some bits of 2.0 such as message driven beans. I think you will need to wait until JBoss version 3 to get full 2.0 compliance.
However I'm just starting on JBoss. Anybody knows better please tell me.
You are right that ActionListener is an interface and generally you could not create it like:
ActionListener myListener = new ActionListener()

However in the code you are defining an anoymous class that implements ActionListener and it is that that gets created.
The anonymous class is defined within the curly brackets immediately after 'new ActionListener()'
As you correctly state the J2EE distribution comes with a reference implementation.
However Sun do not recommend that you use this in a production environment. Two main problems with it.
They do not provide the level of support for it that other J2EE implimentations provide. Also it is not optimised so I would expect it to have poor performance.
If you are worried about cost use JBoss or one of the other open source servers. Also the commercial app servers are started to be given away free, for example HP so its not really a problem.
Unless you override it by calling either explicitely super or this as the first line of the constructor it automatically calls the no-argument constructor of its parent class.
In the case the D no argument constructor has a Print() call which is why two lines appear.
The reason whether it uses Class Es Print method or Class Ds is down to normal method overriding. Note that as both classes are in the default package they are in the same package which is why the default scope works as well.
Hope that helps
[This message has been edited by Phil Sharp (edited December 11, 2001).]