I am trying to launch only listener for both instance. I've modified the tnsnames.ora to look as follwoing.
(ADDRESS = (PROTOCOL = TCP)(HOST = pc1)(PORT = 1521))
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
This is probably (almost certainly) not correct, but you can "make" it correct.
You will need to modify one (or both) "listener.ora" configurations, to make one listener listen on port 1521 and the other on port 1522. You would also need to alter the pfile/spfile for at least one database to make it "register" with listener running on port 1522, or alternatively, hard-code the services into your listener.ora file(s).
If you really want, you can do this, but that doesn't mean its a good idea.
The simplest, cleanest, and easiest way to go would (probably) be to have only one listener (I would run it from the EE ORACLE_HOME myself) listening on port 1521. That will very probably meet your needs. If you want to avoid surprises, though, you may want to "disable" the listener in the non-active ORACLE_HOME. You can do this by removing (or making unreadable) the listener.ora file or by removing execute permission on the 'lsnrctl' executable. (The latter assumes Linux...)
You have 2 files in $ORACLE_HOME/network/admin - the TNSNAMES.ORA is from the client perspective (and remember that SQLPlus as well as a database's DBLINK are both clients) and the LISTENER.ORA is from the server perspective.
The sample you give is from the tnsnames.ora - the client. Suggest you only use one port. The listener listens on that port, looks whether it handles the database, tells the database to prepare for a connection, tells the client and the database what port to use for actual work, and then gets out of the way.
After that, you could also force the listener to act on behalf of specific instance by changing the listener.ora ... save a copy of the listener.ora you currently have as a backup and, in the SID_LIST_LISTENER (that is the list of SID used by listener called LISTENER) you could modify the list of SIDs to include XE, something like ...
This is a good opportunity to dig into the ORacle documentation.
For distributed transaction purposes, Oracle needs to ensure that all Oracle databases (that could be in a distributed transaction) are unique in the world. SO they have a construct called 'global db name' that permits a dot-based suffix for discrimination. So my XE database should be 'XE.fuzzy.forbrichconsulting.com'
I would not agree with one listener per machine from my experience but I wonder what Oracle's current recommendation is???
I found it very useful in the past to have multiple listeners for multiple production databases, especially if they have different business owners. If one group of users flood the listener then the other databases/listeners can work away unaffected. I have also seen one listener on a box crash (admittedly way back in version 7) and it's much better if this only affects one database.
The other benefit I found with multiple listeners per box is it gives additional options for maintenance. For example, I could shutdown one listener to prevent new connections from the application server over tcp/ip to one database while still allowing a connection directly on the server as the application user so new schema items could be deployed etc. Meanwhile all other databases/listeners function as normal.
There are specific reasons for having multiple listeners as you describe.
However, many people do not understand the function or the listener and believe that we need one listener per database instance. That is NOT one of the reasons for multiple listeners.
The listener is only used to initiate a connection - proven by connecting to the database, shutting the listener, and noticing that the connection still works. (As you note.)
For people who do understand the listener, the Rule of Thumb (ROT) could be "one listener per connection style for all the instances on the box". Style can include: protocol, GIOP/RMI vs database separation, maintenance access, port, possibly reservation for dblink-only traffic, grouping users, etc. Basically, different listeners are needed to handle different client requirements and support turning them on/off independently.
Users 'flooding the listener' sounds like an opportunity for connection manager.