Hi I�m sorry if I my questions are to silly, but I think I have some perhaps important suggestions. My experiences come from extensive use of SQL-Databases (mssql-Server and Oracle) in the ERP-Environment. 3-Tier (SAP R/3) and 2 Tier (our own Product for smaller customers). In both products in principle dirty reads are used, so there are totally no locks set when doing querys without intending to writing anything. The products are able to distinguish between those uses. The actual locking has been done in R/3 by handling there own logical locks which are much more course-grained than the row-level-locks which are later used for synchronising the actual writing. In our own product there is no read-locking at all. All synchronising is done by optimistic locks which in seldom cases lead to rollbacks during attempted writes. This made it possible to avoid deadlocks and made it possible to use extensively separate connections for each sql-Server cursor. This has been necessary because of a speciality of SQL-Server-Cursors which means there is a very (10 times compared to the others) fast type of cursor with the big drawback that only one per connection can exist. Such a connection is not relevant in a transactional-sense at all because there are no locks set. So no 2PC is needed, that means I would like it to be avoided. I would like it to be reused without a real closing by the environment, but I think minerva would handle this, on the other side I would like it to be reused depending on the actual statement which was called the last time on it so I would be able to avoid the Preparing and could just rebind my parameters and execute again. In the case of very small resultset but frequent calls this brought a very substantial performanceimprovement on both databases. I talked only about querys and I concentrate on them because in our environments these are by large (90 %) the most frequent uses of the database layer. I would like to be able to separate this kind of query-connection from actual changing connections and would like to discuss it with you. Perhaps I could implement this by wrapping an actual jdbc-layer by myself and putting this below jBoss. Hope I been understandable enough, and hope not to be to frustrating because of talking about this old legacy-stuff, perhaps I can contribute a little bit ? Sincerely Andreas -----Urspr�ngliche Nachricht----- Von: Aaron Mulder [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 19. September 2000 18:57 An: jBoss Developer Betreff: Re: [jBoss-Dev] Transaction - Connection Scope Hmmm... Then I'm not sure we really want to "fix" the transaction handling in Minerva. Let me restate the problem, and hopefully everyone can jump in: Minerva assumes that a connection will be closed before it is committed or rolled back. This works great with container-demarcated transactions, since it means the connection must be opened and closed within one method call, which is the desired behavior. This does not allow you to keep a Connection in an instance variable, but that's good - it prevents a large number of connections from being locked out of the pool. The potential problem here is bean-demarcated transaction handling, where the bean may open a transaction, open a connection, commit the transaction, close the connection. This would break. If you reverse the last two steps, it works fine. If the connections stayed associated with the transaction, this would be bad, since you could commit several times before closing the connection. However, if (as Charles describes below) the transaction ends when you commit, then the problem code above would leave your connection open with no transaction associated, which would definitely be bad - so maybe it's OK to throw an exception in this case. Kind of heavy-handed, but it closes a big potential problem. How do you people feel? I think we're helping people in the long run if we leave things like they are. Now, here's a related question. If you open a connection, *then* start a transaction, the connection is not associated with the transaction. That is also bad (and probably not what you intended), but I don't see anything we can do about it - other than maybe throwing an exception in executeUpdate if you're using the XA wrapper and there's no current transaction. Aaron On Tue, 19 Sep 2000, Charles Crain wrote: > Once you commit/rollback, the transaction is gone. Any more work you do will > be out of transactional scope until you call begin() again. As far as how > long they may be associated, transactions have a timeout that is > user-specified (in one of the xml files, I forget if it is ejb-jar or jboss), > after which they will effectively auto-rollback. The timeout is implemented > via some classes in org/jboss/util. > > -Charles
