Hi, Yes the Default cache is container wide. You should use the CachePerBrokerImpl to use separate cache regions for each jcdAlias.
Thomas > -----Original Message----- > From: Wayne Kidd [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 30, 2003 3:01 AM > To: [EMAIL PROTECTED] > Subject: Re: Mapping classes to multiple data sources > > > I am trying to use the multiple datasources in the way of the current > solution. That is, I have 2 jdbc connections, each of them > has a full > set of the same tables. Therefore, only the jcdalias and its > parameters > are different. It turns out that they are schemas in the > same instance > of Oracle. Therefore 1 of the logged on users has USER1.TABA and the > other has USER2.TABA. The Class Descriptors are precisely the same > (since we do not specify the Schema name in the Class Descriptor of > TABA. This actually works up to a point. I am able to get an object > from USER1.TABA with key X. I can also get an object from USER2.TABA > with key Y. However, if I try to get an object from > USER2.TABA with key > X, I am returned the object even if it does not exist in > USER2.TABA. I > suspect this is due to cacheing, but I have not yet been able > to prove > that. I would rather not have to deploy the thing as 2 separate web > apps (not even sure that would solve the problem - maybe the cache is > container-wide). Does my speculation make sense (and if it does not, > what might be the real problem). > > > Thanks in advance > > Wayne > > > > I think this description is not very accurate. A long time ago we > > allowed to have different JDBC connections defined per class. > > > > But we dropped this feature, because it involved complex problems. > > For example it required us to provide a proper 2 phase > commit across > > multiple databases. > > > > The current solution is much simpler. A PersistenceBroker instance > > works with a dedicated Jdbc connection identified by a > jcdAlias in the > > repository.xml. > > So it is possible to work with one Broker for database A and with a > > second broker against database B. > > > > So it's still possible to persist objects to different > databases. But > > the management (e.g. 2phase commit) must be implemented by > user code. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
