Hi, > > > careful to do such things only on a repository that is *not shared* > across > > > multiple brokers. > > > If you perform this operation after a > PersistenceBroker.beginTransaction() > > > call, > > > this operation is threadsafe: > > > A broker can only perform one transaction at a time. So once you > open a > > > tranaction on a broker instance, other threads won't be able to > perform > > > transactions on the same broker instance! > > Think this could be problematic, cause the broker is now thread-safe, > but the descriptor-repository instance obtained by the broker was shared > anymore. Or did i overlook something?
Is there missing a NOT in this sentence, or ? Do you question the information Thomas provided ? > > Ok - this sounds great, now I just have a couple of questions (that > might > > already be answered in the FAQ, but I just wanna be sure :) > > > > If I have a J2EE application running in a single JavaVM which have > multiple > > threads/clients using the same repository - how does I ensure that 2 > clients > > does not use the "same" repository ? Does one have a pool of > > PersistenceBrokers ? And how are these persistencebrokers created so > they do > > not share the same INSTANCE of a repository but have the same model > (e..g > > read from the same repository.xml?) > > > > And on a sidenote: I which state is the J2EE integration ? Can OJB act > as a > > XA-compliant resource in a JTA-transaction ? > > Currently (not checked in) the jboss mbean integration seems to work > again. We will check in this stuff in the next days. > > Hope we are able to start with the JCA implementation in the near > future. If OJB currently is not JCA aware - how do you ensure transactions etc. on J2EE servers today ? (this goes for both Servlets and EJB's) Are there threadlocals that one should be concerned about ? /max -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
