This will avoid data corruption, but is probably not going to be what you want to do. I've never noticed any issues mounting the volume read-only on another node. Even if something doesn't match up on the ro node usually that just throws a "unexpected free inode, please run e2fsck" or the like into /var/log/messages. If something is dreadfully unexpected about a non-critical filesystem ("/opt/mySpecialmount") usually Linux will just mount the volume read-only (which hey, we're already there). If you're super worried about what effect caching has, you can try to get some sort of drop_caches/vfs_cache_pressure regime going.
To avoid replaying the journal add "noload" to the mount args, do that along with errors=remount-ro (just to err on the side of caution).
That said, chances are that if you're OK with mounting it read-only, it's probably just as a reference for the other node, in which case NFS or smbfs would solve the issue and is designed for a little more concurrency than ext3/4 would be. If you need performance then you could look into a clustered filesystem (little more administrative overhead, but it's there if performance really is something you need).