Been reading for two weeks about this issue.
So far, I can sum up as this:
* If your entities belong to different databases, you can not define any one-to-one, many-to-one, nor one-to-many relationship at all.
There are several posts that show you how to deal with this issue, when the n-databases are, actually, n-catalogues within same database.
Another strategy I read about, relies on database linking (if at least, supported by one of the DBMS to "every" other you need to use).
In these two scenarios, you will be dealing with only one sessionFactory.
Again, so far, I couldn't find any post anywhere, showing how to work with entities from different SessionFactory(ies). I assume you have to do the wiring on your own: after you get your A entities (using hibernate), cycle through them, then get (using hibernate) & manually "link" your B entities to the A(es).
Regarding "relationship" persistance, when cascading option applies, you will have to handle it on your own. A and B entities, each can be updated in their own container session. The relationship will be saved in a regular property(ies if composite).
Hope to see anybody telling this is not right and posting a solution to this issue. Good luck.
PS: links related:
http://forum.hibernate.org/viewtopic.ph ... +databases
http://forum.hibernate.org/viewtopic.ph ... base+mysql
http://forum.hibernate.org/viewtopic.ph ... +databases
http://forum.hibernate.org/viewtopic.ph ... +databases
PS2: Check whether Shards is an option. Perhaps there is a "place" for Shards. Not sure how it works, but conceptually you may create one shard pointing to a dummy table and the second shard pointing to the real table in 2nd DB. Not very sure about this, since it is supposed to be horizontal partition, whether you will be able or not to hit diff DBs.