On Sat, 21 Aug 2004 15:53:30 +0200, Armin Waibel <[EMAIL PROTECTED]> wrote:
Hi Armin, >Hi again, > > > > > I think this one happend during lazy loading of a list proxy. So would > > this mean that > > - we should not use reference and collection proxies when working with > > the ODMG API (this would be a heavy blow) > >In a normal servlet environment this should be work. Only when using OJB >within EJB it is not possible to use lazy loading, because the client >(e.g. webserver in 3-tier environment) does not know about OJB (or the >collection proxy itself has to be a bean). > > > > - or that we should not use objects with unmaterialized proxies > > outside of a transaction? (I think we don't do that normally, but > > there might be some cases where we do.) > >hmm, this should work. Could you describe more exactly what your test >do? Does the test operate on the same objects, does insert new object, >read, delete,... Were does the issue happen? > >It will be time-consuming but we first need to reproduce your issue with >an standalone unit-test. > >regards, >Armin > Sorry for not responding earlier. We are trying to fix our problems piece by piece, and a good part of them seems to be due to the quirky locking behavior of DB2. (And another part to the quirky v4 connection pool in WebSphere.) But we also had to work around some issues with OJB, which might be of interest for the list: 1) Occassionally we run into a thread deadlock situation when the connection pool of the app server is exhausted. The reason is that the LockManagerDefaultImpl is completely synchronized: When constructing an Identity for a new object, it has to obtain a connection from the pool to get a sequence number from the database. Now the pool blocks, because it is exhausted and the LockManager blocks all other threads that could release their locks (and afterwards their connections). Looking at the LockManagerDefaultImpl code, I actually see no reason why its methods need to be synchronized. Am I overlooking something? 2) As a workaround to resolve deadlocks between DB2 and the Java App we are trying to use timeouts on the statement level (Statement.setQueryTimeout()). In principle this works, but another quirk of DB2 (or its JDBC driver) is that the resulting timeout exception is not thrown in the stmt.executeQuery() method but later when iterating through the resultset. Now OJB's RsIterator simply ignores exceptions thrown from the rs.next() call and treats them exactly the same as if rs.next() had simply returned false. The result is that the application has no notion that a timeout occurred and simply gets an incomplete query result. Patching RsIterator to propagate exceptions from rs.next() solved this problem. Was there a reason to ingore all exceptions there? 3) When resolving issue (2) we found the best place to set the statment timeout in the afterStatementCreate method of the Platform interface. However, although almost everything in OJB seems to be configurable, the platform to class mapping is hardcoded in a pretty ugly manner (sorry for that... ;-) in the PlatformFactory. Are there any plans to make the PlatformFactory as nicely configurable as most other factories? Thanks, Gerhard --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
