Nilesh Pereira

Residential DSL typically maxes at 1.5MBps while cable maxes at 10MBps. The difference? The bandwidth you get with DSL is all yours to use in any way or form. With cable, you share the bandwidth with your neigbours. And cable companies reserve the right to arbitarily terminate your connection because of excessive use. Some of them are even considering implementing bandwidth caps. On an average, tho', cable is faster than DSL.

Okay, well in that case, I'm glad I got it wrong
These brits are crazy...

Originally posted by Richard Hawkes:
Matrix quiz:
http://film.guardian.co.uk/quiz/questions/0,5952,957691,00.html

The only question I got wrong:
Who or what is the Littlest Hobo?

Usually, all the RemoteUPAWrapper instances will reside in the JVM they were instantiated. If you need separate JVMs for each instance you can do that by making your RMI object an Activatable RMI object. You need to implement the java.rmi.activation.Activatable interface, as well as register it with the RMI daemon (rmid) I think. You can then choose whether to activate the RMI object in the same JVM or a new one. Making the RMI object Activatable gives several other advantages including some sort of pooling and wake up capabilities. You'll have to look it up for more detailed information.
I haven't used JDK 1.4 or it's new logging mechanisms yet, so I can help you with that. But I'm sure there are plenty of other ranchers who are up to speed with the latest and greatest JDK.
BTW I found a pretty good collection of RMI links including one for using a Factory with RMI objects! Check http://www.dickbaldwin.com/javalinks/jaxarmi.htm out.

Right. And if you add thread pooling and transaction support you will have implemented an EJB 1.0 container! Are you sure this solution is not an overkill for your problem? Could you not just make your object a Stateful Session EJB and use an off-the-shelf EJB container? I must admit, though, that this would be fun to implement yourself...

1) How do I programmatically (from my object pool) determine if the unreferenced() method has been called for a particular remote object?

The RMI runtime calls the unreferenced() method on your RMI object when it's no longer referenced by any clients. It's then upto your object to transfer itself from the used pool to the available pool.

2) If it's true I can't bind it to the registry how do I make it available for remote access? It seems like it's not very useful if you can't bind it to the rmiregistry.

Well, you won't need to bind the individual instances of RemoteUPAWrapper to the registry. You will need to make the SessionController a Remote object, and bind it to the registry. The factory will then only lookup the SessionController, and the SessionController will return a RemoteUPAWrapper reference from the available pool.

Is there a way to determine from the my RMI Server (SessionController) whether a client is still using a reference to one of the sessions?

Yes, there is, though I have never used it. I think the RMI object will need to implement the java.rmi.server.Unreferenced interface. The RMI runtime calls the unreferenced() method when there are no more clients referencing the object.
I think it treats the RMI registry as a client too, so you won't be able to bind the references to it.

I found http://www.voelter.de/data/articles/aop/aop.html to be a good starting point.
There is a pretty extensive listing of AOP links at http://www.iturls.com/English/TechHotspot/TH_e.asp.
[ April 25, 2003: Message edited by: Nilesh Pereira ]

when we say the statement is pre-compiled what internally happens because i believe when the query is fired to the database, the database tries to compile the statement, which will be extra work as the sql statement is pre-compiled at java layer and also at the database layer

Okay, let me try again
It is not extra work, because the Prepared Statement is NOT compiled when the query is fired. Rather, it's compiled when the PreparedStatement is created/prepared.

I know. I was trying to explain this:

when we say the statement is pre-compiled what internally happens because i believe when the query is fired to the database, the database tries to compile the statement, which will be extra work as the sql statement is pre-compiled at java layer and also at the database layer

Also, why it pre-compiles, and when it is useful to pre-compile.

Does that mean I have to stop coding in vi???
Thanks Gopi, Ilja for your insightful comments. I think I'm ready to get my feet wet now
If anyone wants to post their thoughts or experiences using AOP, please continue to post on this thread. Thanks.

Lasse, could you please explain how the EJBHome satisifes the intent of the GoF FactoryMethod pattern. Thanks, I would appreciate it.

A Statement will always proceed through the four steps in the database for each SQL query sent:
(1) Parse the SQL query
(2) Compile the SQL query
(3) Plan/optimize the data acquisition path
(4) Execute the optimized query
This can be a performance issue if you are executing the same SQL over and over again. A PreparedStatement takes advantage of repeated queries by pre-executing steps (1) - (3) when it is created/prepared. Obviously, a PreparedStatement adds no value for dynamic SQL queries like those used in reports.

I guess the basic question is when 2 or more clients make a request from the RMI server for a remote object do they receive a reference to a common instantiation of the object or do they receive references to unique instantiations of the object??

The clients will receive a reference to the same instance of the RMI object. If the clients call the UPAWrapper in a multithreaded environment, and the UPAWrapper is not thread safe, concurrency/synchronization will be an issue. You could either synchronize parts of the UPAWrapper that are not thread safe, or return references to unique intstances of the RMI object for every client request.
If you go that way, the SessionController would have to maintain Session IDs and a pool of used and unused references. The clients would have to inform the SessionController when they are done with their reference so that the SessionController can termintate the session and return the reference to the unused pool.
It almost sounds like you'll be creating your own SessionBean implementation!!!

Here's another question not directly related to our evolving solution. A colleague of mine utilizing RMI for a similar solution advocates using a "SessionController" which dynamically binds a new RMI server to the registry everytime a request is made to his application. The client then makes a request to this dynamically bound server. According to him this guarantees that there will be no concurrency problems if multiple clients are requesting his RMI application simultaneously. What are you thoughts on this implementation and how does it affect our evolving solution?

I'm not sure I fully understand the concept you just explained. How would you maintain the session? Would the client have to inform this Controller when it's done with the remote reference? Will the Controller have to maintain a pool of available and used references?