Hi Armin, thanks for your detailed explanations on PersistenceBroker.close() behaviour.
It now appears, that it was our own mistake. We had some concurrent access problems. After fixing them, the NPEs are gone. So everything's fine with OJB in this case :-) Peter > Hi Peter, > thanks for another brainteaser ;-) > > In fact, we always call PersistenceBroker.close() after each > "transaction" > > and obtain new Instances for further operations (I do not really > > remember > > why we do this, but I guess it was suggested to do so somewhere in the > > tutorials). The problems now occurs when materializing collection or > > reference Proxies, where unfortunately we are unable to intervene. > > > It's recommended to close the used PB handle for better scalability. OJB > manage an internal PB pool (independent from a connection pool - see > ConnectionFactory). When you obtain a PB instance OJB returns a PB > handle (the handle, PersistenceBrokerHandle.java, wraps the real PB > instance released from the pool). > On PB.close the handle returns the real PB instance to pool and detach > used resources, thus the handle was invalid after PB.close() and should > throw an exception on further use. > When the used real PB instance was returned to the pool the used > DescriptorRepository was detached (this seems to cause your problems) > and if a connection was associated with the broker (e.g. when you only > do read operations) it will be released by the ConnectionFactory (means > closed or returned to the used connection-pool). > So, on PB.close() it is guaranteed that the used connection was > released. The DescriptorRepository was detached because OJB allows to > use different metadata models on a per thread base. The PB handle was > among other things used to avoid user references to pooled PB instances, > because this would case problems (e.g. different user use the same PB > instance). > > Could anyone tell me whether this workaround is safe and what could be > > a > > gould strategy to avoid these kind of problems? > hmm, you shouldn't get these kind of problems. The NPE could only occur > when you directly use a pooled PB instance. > By the way do you use OJB in a managed environment with > PersistenceFactorySyncImpl? > > Is it really necessary to > > close PBs all the time? > Necessary no, but recommended see above. > regards, > Armin > Peter Wieland wrote: >> Hi all, >> >> we have a problem with closed persistence brokers. Maybe it is selfmade. >> I >> just would like to have your opinion. >> >> First the symptoms: >> >> From time to time I get NullPointerExceptions in >> PersistenceBroker.getTopLevelClass() and >> PersistenceBroker.getClassDescriptor(Class clasz). Both are caused by >> PersistenceBroker instances that are closed and whos internal >> descriptorRepository is null. >> >> In fact, we always call PersistenceBroker.close() after each >> "transaction" >> and obtain new Instances for further operations (I do not really remember >> why we do this, but I guess it was suggested to do so somewhere in the >> tutorials). The problems now occurrs when materializing collection or >> reference Proxies, where unfortunately we are unable to intervene. >> >> As a very dirty workaround, we use our own PB implementation extending >> PersistenceBrokerDefaultImpl. We make sure that the descriptorRepository >> variable is always accessed through a getter, that checks whether the PB >> is >> closed and calls setClosed(false) if it is. The problems disappeared, but >> I'm afraid, this may cause other problems as I do not know what effects >> closing a PB and calling setClosed(false) afterwards has. >> >> Could anyone tell me whether this workaround is safe and what could be a >> gould strategy to avoid these kind of problems? Is it really necessary to >> close PBs all the time? >> >> Thanks, >> >> Peter >> >> --------------------------------------------------------------------- >> 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
