Using MapViewer from PL/SQL vs Java

Question

Hi group!
The MapViewer User's Guide has this to say about using MapViewer from PL/SQL:
"The usage model for the SDO_MVCLIENT package is almost identical to that of
MapViewer JavaBean-based API" etc etc .. "For usage and reference information about specific functions or procedures, see the description of the associated JavaBean-Based API. methods and interfaces in Chapter 4"
If I don't misunderstand the basic concept, in a Java Web App (using the MapViewer Bean) you create a MapViewer object for each HTTP-user-session, like so:
MapViewer mv = new MapViewer("http://my_corp.com:8888/mapviewer/omserver");
... which you would then store in the user's session object, so that the MapViewer Bean conveniently holds the map's state on the user's behalf.
To do the equivalent in PL/SQL, the User's Guide suggests:
"connect scott/tiger
call sdo_mvclient.createmapviewerclient(
'http://www.mycorp.com:8888/mapviewer/omserver') ;
The preceding example creates, in the current session, a unique MapViewer client
handle to the MapViewer service URL"
Does "current session" refer to the HTTP-user-session? While I've used PL/SQL before, I've not used the PL/SQL Web Toolkit. Is the session handling implicit here (and invisible?) or should the sdo_mvclient be subsequently stored in the PL/SQL equivalent of a (J2EE) HttpSession object?
YT

Answer 1

Part of the answer will depend on how you plan to deploy the application. If you have a few, local clients you could go with the traditional client/server model. If you have a lot of clients and/or they are spread out over a relatively large area (like a campus setting), a web front-end will save you a lot of hassels down the road when it comes time to upgrade.
Regardless of the the front end, I can tell you that I have been greatly impressed with the throughput you can get by moving most of the code to PL/SQL packages. A few years ago we reworked a VB/Oracle app by moving a lot of the code out of VB and into packages, leaving the client to essentially call procedures and format the output. We had more than a 3x performance increase on the same hardware and our network utilization decreased noticably.
I am now in the process of replacing the client code with Java servlets/JSP, primarily because of the maintenance hassles I mentioned earlier. There are some limitations with an HTML page but most of these have been cosmetic so far.
We are still relying heavily on PL/SQL packages. The servlet code basically gets a request, calls a package to get the data, then hands the results to a JSP page. The JSP then formats the output and sends it to the client. We are little more than halfway through the re-write, but it appears performance will increase again. Not as noticably as before, but I will take what I can get. As you have seen, once something is rolled out it always ends up getting used more than you anticipated. Better to over-engineer now than have to patch it once it is live.
HTH