Multi instance on same server

Question

This is my first experience trying to load and set up Oracle from the dba point of view and I need some guidance. I have started having problems when loading 9i on the same server as the 8.1.7 instance. It wanted to overwrite files and was using the same ORACLE_HOME and ORACLE_BASE for some files as I used in the 8.1.7 install, which I don't want since the products are loaded in different directories. Wherever possible, I specified a different HOME and BASE but apparently Oracle has a few places where it doesn't ask.
My intent: the database is in 8.1.7, no immediate intent to upgrade. Huge db. I am creating a 9i instance on the same Sun server to support iFS and a small subset of the data from 8.1.7. iFS will check the 9i table, create some xml id files that correspond to the records in the 8.1.7 db. There'll be views and a link between the instances to support fast refreshes to keep them in synch.
I think my problem lies in the file structure and where the profiles are. My .kshrc file references an application shell for the environment setup near the top of the file structure. That shell needs to support both environments or be split I think.
Can anyone suggest a file structure to support both installations without conflict and where the shell should be and how to implement it so I don't have conflicts?
thanks
Pat

Answer 1

the jury is still out to a degree, but i think we've identified the culprit(s) of our session bleed for anyone interested.  it boiled down to two problems.
1.  var scoping issues.  unfortunately this was a fairly old application, written before we strictly employed best pracitices on var scoping variables within functions in all our cfc's.  we've fixed the bad code and our session bleed problems seemed to have stopped.  there is a great utility for checking code for var scoping problems available at: http://varscoper.riaforge.org/
2.  a misunderstanding of how cflock with a timeout setting (and no throw on error)  behaves.  aside from session bleed, it turned out we had another issue in there, which was expected session values missing all together.  the crux of the problem is that we had set our cflock read/write timeout's to 30 seconds.  under the extremely heavy load, requests were routinely exceeding those timeout thresholds.  the locks were not set to throw on error, so when the timeout threshold was exceeded, the code within the lock ended up just being skipped.  this was leading to missing data in the session. temporarily we've simply increased the timeout setting to a large number, which has fixed our problem.  eventually we'll set these locks to throw on error and handle the exception in a more graceful manner.
hope this helps someone.