Re: [JBoss-dev] High load...
Hi, David Jencks wrote: On 2001.06.28 08:32:18 -0400 Ole Husgaard wrote: This algorithm may be fine, but it seems to be for commit option A only. As written, yes, as you point out below, reloading from db for each new transaction is necessary for B/C I think we should also consider the other commit options, yes Thinking some more, I do not see how we could support snapshot isolation with other commit options than A without some kind of special resource support for it, because a reload is needed with the other options and a later tx may have changed the DB before the reload, thus violating the snapshot. and optimistic/pessimistic locking. Not sure why we would want more pessimistic locking-isn't that what we have now? Pessimistic and optimistic locking both have advantages, and it would be nice if we could support both, maybe with a per-container setting. transactions are numbered sequentially when they are started. Sorry, but I don't think we can rely on that if we need to avoid dependencies on the transaction service used. (By hacking a special dummy XA resource that is registered with every new tx seen by JBoss, I guess we could get to the Xid, and maintain some kind of mapping from the GlobalID to a serial number. But that looks a bit ugly to me.) I agree this is a potential problem. However I think you don't get snapshot isolation and maybe you might get more deadlock opportunities without it. (I think just read committed isolation) I haven't really looked into it, but I wondered about using the transaction interceptors-- this is where all new transactions come from, isn't it, and its definitely part of the container not the TM? I guess that the problem with snapshot isolation is that the logical locking happens at transaction start, before anything is read or we even know what is about to be read. I have only been thinking about the case where only a single container is involved in the transaction, but such transactions may involve several containers, and even several servers. I cannot see how we could create transaction sequences for multiple servers without some kind of centralized ticket service, giving a single point of failure. I have to warn against the obvious way of doing local transaction numbering: A server-wide WeakHashMap that maps Transaction to Integer. Problem with this is that there may not be a one-to-one correspondence between Transaction instances and the actual transactions they represent. Not long ago, the fast in-VM TX service could create several Transaction instances for the same transaction, and these different Transaction instances could be active at the same time. That is not a violation of the JTA specification. The only sure way we can know if different instances are the same transaction is by looking at the Xid of the transaction. Unfortunately JTA only exposes that to resources. When you change an entity, a new version is put in the cache with your transaction id ( of course no one else can see it till you commit: the entity versions need both the transaction sequence and some way of telling if they are committed.). I guess we could call isModified() after each invocation to avoid creating a new version until the entity is actually modified. But that means that we would use the same entity version for different transactions, and since it is too late to get the unmodified entity version after isModified() returns true, wouldn't we have to create another version before the invocation anyway? After I wrote this I thought about it some more. I think it can only be made to work with ejb 2 abstract accessors-- as you say I think for ejb 1.1 beans we need each transaction to get a copy in case they want to modify something, we can't tell. I actually don't know if the ejb 2 beans can store state outside of their abstract accessors. If so, they too would need instance/transaction in case whey changed state. If not, at least conceptually copy on write is possible. Entity bean _can_ have state besides what is saved in ejbStore(), but: The bean cannot rely on such state information to be saved, because what can be done in the ejbPassivate() is quite limited (runs in an unspecified transaction context, and may _not_ access resources). Problem with copy-on-write is that we do not know before the invocation returns if an invocation is a write (ie. changes the state of the instance). And without the isModified() method we do not know at all. It would be nice if the bean provider could declare methods as being read-only. I guess we have two options here: We could choose _not_ to copy before the invocation. That means that we do not have an unmodified cached instance ready, and that we may have to do an ejbLoad() to get one if/when we need it. (Guess this one will not work with snapshot isolation.) We could choose to always copy before the invocation, and throw away the copy if
Re: [JBoss-dev] High load...
On 30 Jun 01, at 16:19, Ole Husgaard wrote: I have to warn against the obvious way of doing local transaction numbering: A server-wide WeakHashMap that maps Transaction to Integer. Problem with this is that there may not be a one-to-one correspondence between Transaction instances and the actual transactions they represent. Not long ago, the fast in-VM TX service could create several Transaction instances for the same transaction, and these different Transaction instances could be active at the same time. That is not a violation of the JTA specification. The only sure way we can know if different instances are the same transaction is by looking at the Xid of the transaction. Unfortunately JTA only exposes that to resources. Hi Ole, I wanted to ask about this... The JTA spec requires (in 3.3.4) that the Transaction object's equals and hashCode methods be overridden to return true or the same hash number, respectively, if the target object and parameter object both refer to the same global transaction. These are enough to ensure a HashMap functions correctly, and to allow us to find out if different instances refer to the same transaction. Did I misunderstand your point (or perhaps the spec)? -Dan ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, Dan OConnor wrote: On 30 Jun 01, at 16:19, Ole Husgaard wrote: I have to warn against the obvious way of doing local transaction numbering: A server-wide WeakHashMap that maps Transaction to Integer. I wanted to ask about this... The JTA spec requires (in 3.3.4) that the Transaction object's equals and hashCode methods be overridden to return true or the same hash number, respectively, if the target object and parameter object both refer to the same global transaction. These are enough to ensure a HashMap functions correctly, and to allow us to find out if different instances refer to the same transaction. Did I misunderstand your point (or perhaps the spec)? You are absolutely right: I was wrong here. Thanks for reminding me. And worse: I have to go fix a bug in the class org.jboss.tm.TransactionImpl to be spec-compliant. Best Regards, Ole Husgaard. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, (Just brainstorming here, sorry if I'm wrong.) This algorithm may be fine, but it seems to be for commit option A only. I think we should also consider the other commit options, and optimistic/pessimistic locking. David Jencks wrote: Hi, the algorithm is in the post marc was replying to. Here it is again, with garbage collection instructions and referring to entities rather than records. transactions are numbered sequentially when they are started. Sorry, but I don't think we can rely on that if we need to avoid dependencies on the transaction service used. (By hacking a special dummy XA resource that is registered with every new tx seen by JBoss, I guess we could get to the Xid, and maintain some kind of mapping from the GlobalID to a serial number. But that looks a bit ugly to me.) Each entity (version) includes the transaction id of the last change to it. When an entity is first loaded from the db, the transaction id of the transaction in which it is loaded is associated with the entity version. When you find an entity (within a transaction), you get the entity version with the largest transaction id = your transaction id. I think a DB load of the entity is needed, if the entity has not yet been loaded in that particular transaction. You want to see uncommitted changes made from elsewhere in the same transaction to the database representation of the entity. (That is, if you do _not_ use commit option A.) When you change an entity, a new version is put in the cache with your transaction id ( of course no one else can see it till you commit: the entity versions need both the transaction sequence and some way of telling if they are committed.). I guess we could call isModified() after each invocation to avoid creating a new version until the entity is actually modified. But that means that we would use the same entity version for different transactions, and since it is too late to get the unmodified entity version after isModified() returns true, wouldn't we have to create another version before the invocation anyway? The older versions hang around until no transactions are active that could see them, then they are garbage collected. (see below) There is a transaction property that determines behavior when two transactions try to modify the same entity: either you get an immediate exception or your changes block until the other guy commits (you get an exception) or rolls back (your transaction succeeds) If we should be optimistic here, I think that we should get two different versions of the same entity here, each with their own context associated with a different transaction. If both are changed, the last transaction commit should fail, as we might have an unresolvable update conflict. But if one of the entities are not changed, the commit of the transaction it is associated with needs no database update, and that particular entity version can be thrown away at commit time (even if other transactions have made (and possibly committed) changes to other versions of the same entity). Note that only the most recent (committed) version can be modified by any transaction, and that the blocking/ exception behavior just described only applies to 2 transactions trying to modify the most recent committed version. Each transaction as it starts is put on an ordered (by transaction sequence) list of active transactions. When it is committed or rolled back, it is removed. The first transaction on this list is the oldest active transaction. The transaction associated with the oldest entity version we have to keep around is the oldest interesting transaction. Lets suppose we have an entity with versions for transactions t1, t7, t11,... We can discard the version for t1 when the oldest active transaction is at least t7, because all transactions that could possibly reference that version have completed. Note that this results in snapshot transaction isolation rather than read committed. (I don't know how read committed is implemented, and don't know why you would want to use it). I confess I don't quite understand how snapshot differs from serializable isolation -- its certainly close. This requires a version for each modifying transaction, rather than a single version or a version for each transaction. You may need to keep several committed versions around at once until all transactions referencing them are complete. I don't think we need this strict ordering of transactions. If we want to do optimistic transaction locking, we need a cache that supports multiple versions of each entity (one for each transaction that the entity is participating in). If we have that, and use commit option A, we just need a reference to the version last committed. However, if we pick that version to use in a tx, we might need to clone it, as we may need it again for yet another tx. Interbase versioning is per transaction , not per
Re: [JBoss-dev] High load...
Hi, I agree with almost everything you say. On 2001.06.28 08:32:18 -0400 Ole Husgaard wrote: Hi, (Just brainstorming here, sorry if I'm wrong.) This algorithm may be fine, but it seems to be for commit option A only. As written, yes, as you point out below, reloading from db for each new transaction is necessary for B/C I think we should also consider the other commit options, yes and optimistic/pessimistic locking. Not sure why we would want more pessimistic locking-isn't that what we have now? David Jencks wrote: Hi, the algorithm is in the post marc was replying to. Here it is again, with garbage collection instructions and referring to entities rather than records. transactions are numbered sequentially when they are started. Sorry, but I don't think we can rely on that if we need to avoid dependencies on the transaction service used. (By hacking a special dummy XA resource that is registered with every new tx seen by JBoss, I guess we could get to the Xid, and maintain some kind of mapping from the GlobalID to a serial number. But that looks a bit ugly to me.) I agree this is a potential problem. However I think you don't get snapshot isolation and maybe you might get more deadlock opportunities without it. (I think just read committed isolation) I haven't really looked into it, but I wondered about using the transaction interceptors-- this is where all new transactions come from, isn't it, and its definitely part of the container not the TM? Each entity (version) includes the transaction id of the last change to it. When an entity is first loaded from the db, the transaction id of the transaction in which it is loaded is associated with the entity version. When you find an entity (within a transaction), you get the entity version with the largest transaction id = your transaction id. I think a DB load of the entity is needed, if the entity has not yet been loaded in that particular transaction. You want to see uncommitted changes made from elsewhere in the same transaction to the database representation of the entity. (That is, if you do _not_ use commit option A.) Agreed When you change an entity, a new version is put in the cache with your transaction id ( of course no one else can see it till you commit: the entity versions need both the transaction sequence and some way of telling if they are committed.). I guess we could call isModified() after each invocation to avoid creating a new version until the entity is actually modified. But that means that we would use the same entity version for different transactions, and since it is too late to get the unmodified entity version after isModified() returns true, wouldn't we have to create another version before the invocation anyway? After I wrote this I thought about it some more. I think it can only be made to work with ejb 2 abstract accessors-- as you say I think for ejb 1.1 beans we need each transaction to get a copy in case they want to modify something, we can't tell. I actually don't know if the ejb 2 beans can store state outside of their abstract accessors. If so, they too would need instance/transaction in case whey changed state. If not, at least conceptually copy on write is possible. The older versions hang around until no transactions are active that could see them, then they are garbage collected. (see below) There is a transaction property that determines behavior when two transactions try to modify the same entity: either you get an immediate exception or your changes block until the other guy commits (you get an exception) or rolls back (your transaction succeeds) If we should be optimistic here, I think that we should get two different versions of the same entity here, each with their own context associated with a different transaction. If both are changed, the last transaction commit should fail, as we might have an unresolvable update conflict. This is also possible, as soon as the first transaction commits it sets the other(s) Rollback Only. Throwing an immediate exception or waiting prevents the 2nd transaction from wasting time doing work that will be rolled back if the first transaction commits. It may also be easier to keep track of. But if one of the entities are not changed, the commit of the transaction it is associated with needs no database update, and that particular entity version can be thrown away at commit time (even if other transactions have made (and possibly committed) changes to other versions of the same entity). yes, the blocking/exception is only when 2 transactions try to modify the same data at once. Unlimited reads of all versions are fine. Note that only the most recent (committed) version can be modified by any transaction, and that the blocking/ exception behavior just described only applies to 2 transactions trying to
RE: [JBoss-dev] High load...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Wednesday, June 27, 2001 9:44 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] High load... Hi, On 2001.06.26 23:30:32 -0400 marc fleury wrote: |2 entity beans. 2 connection pools(but same database), each connection pool |is configured to use a certain JDBC isolation level. Entity 1 is attach to |pool 1, Entity 2 is attached to pool 2. yuck... I still don't have a clear answer to what we do = (does a jdbc connection support setting isolations level on the fly)? we use one pool and the container sets levels : we are stuck with many pools Well, a jdbc connection certainly supports setting isolation levels. I think when you can do it depends on the db. I think generally it only makes sense to change when there is no uncommitted work (between transactions), even though apparently some dbs (someone said informix) may let you change within a transaction. marcf PS: of course many pools works but yuck! | |1. Start JBoss transaction |2. Access Entity1. A connection is grabbed from pool 1, |connection1.setIsolation(blah blah), |3. access entity2. A connection is created from pool 2, |connection2.setIsolation(blah blah) |4. End JBoss transaction. commit is called on connection 1 and connection |2. | |This should work, shouldn't it? | Well, maybe. To make this work, you require true xa capable drivers, and you need to use real 2pc, not the fake stuff from jbosspool wrappers. The wrapped drivers will give you 2 independent conncurrent transactions. I don't know about you, but I'm happy with the fake XA that the jbosspool wrappers provide. Shouldn't it work 99.999% of the time? Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
On 2001.06.27 10:55:10 -0400 Bill Burke wrote: snip | |1. Start JBoss transaction |2. Access Entity1. A connection is grabbed from pool 1, |connection1.setIsolation(blah blah), |3. access entity2. A connection is created from pool 2, |connection2.setIsolation(blah blah) |4. End JBoss transaction. commit is called on connection 1 and connection |2. | |This should work, shouldn't it? | Well, maybe. To make this work, you require true xa capable drivers, and you need to use real 2pc, not the fake stuff from jbosspool wrappers. The wrapped drivers will give you 2 independent conncurrent transactions. I don't know about you, but I'm happy with the fake XA that the jbosspool wrappers provide. Shouldn't it work 99.999% of the time? Bill It depends how critical data integrity is to you. If you have only one resource/pool, they work fine, because you only need 1pc. If you have more than one resource/pool (as you are suggesting), then if the second branch fails to commit, you are stuck with the first branch having committed, the second rolled back == data integrity failure. If you can guarantee that both transactions will commit when called (for instance deferring fk constraints till end of transaction will not guarantee this), the only thing you have to worry about is something crashing between commit branch1 and commit branch 2. I don't know if there is some way to detect this in the logs, but your db would be in an inconsistent state, with no automatic way of recovering. Whether this is a problem for you is another question, but this is what xa/2pc addresses. david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, bean C is ISOLATION1 and D is ISOLATION2 my question is can we reconfigure connection D with the new stuff? Yes, at transaction start time you MAY call Connection.setTransactionIsolation(int level), the docs only note: 'This method cannot be called while in the middle of a transaction.' regards georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
Howdy, --- Bill Burke [EMAIL PROTECTED] wrote: Databases are freakin' designed for concurrent access. Why not leverage them? I remember reading someplace that WebLogic 6.x was starting to move more of its synching to the database layer. I agree with Bill. I think we should rely on the database's resource manager to handle isolation levels and XA. If there is no such resource manager, then let's create it. Trying to make jboss (jaws, minerva or whatever) compensate for a faulty of missing resource manager(s) will just make us go in circles when problems arise and problems will be recurring in time, I am sure. Now, maybe JCA is better solution than JTA's resource managers I don't really know, what I want to say is let's keep the division of work among modules and let's make jboss code as simple as possible. For what it's worth, thanks, CC __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
I believe Oracle actually throws an exception if you had an existing transaction and you tried to fool around with the transaction setting. Vinay - Original Message - From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 5:19 AM Subject: RE: [JBoss-dev] High load... |I think you missed one of the old messages (way to many today). | |It appears that if you changes the transaction isolation in the middle of a |transaction the driver can perform an implicit commit (YUCK). | |So, I don't think we can trust drivers to allows us to change the level on |the fly. well that is EXCELLENT NEWS... ? you are saying that I can actually change the isolation level on a jdbc connection for a new transaction ? ( I don't want to change in the middle) what I want to do is connection A gets assigned to transaction B transaction B encompasses bean C The container gets connection D Connection D was use with bean E previously bean C is ISOLATION1 and D is ISOLATION2 my question is can we reconfigure connection D with the new stuff? you seem to say that yes...because you are aware of problems that arise if we do it INSIDE a transaction, when I really don't care about this fine a feature... marcf | |-dain |- Original Message - |From: marc fleury [EMAIL PROTECTED] |To: [EMAIL PROTECTED] |Sent: Tuesday, June 26, 2001 10:36 PM |Subject: RE: [JBoss-dev] High load... | | | | Sure, it would be useful to be able to specify different levels per | | bean, but given the apparent constraints that the databases |are putting | | us under, implementing it against the database isn't feasable. | | | | | |Just use a freakin' different connection pool for different beans and |there | |is no freakin' database constraint. | | oh wait reading old stuff, so you are saying that | | (do jdbc connection support setIsolationlevel on the fly) == false | | shit... | | databases is an UGLY world, you know what??? we can do MUCH better at the | distributed cache level so screw delegating to the db... | | I am drunk and it is getting tough to think ... | | marcf | | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | http://lists.sourceforge.net/lists/listinfo/jboss-development | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Bill Burke wrote: Well, maybe. To make this work, you require true xa capable drivers, and you need to use real 2pc, not the fake stuff from jbosspool wrappers. The wrapped drivers will give you 2 independent conncurrent transactions. I don't know about you, but I'm happy with the fake XA that the jbosspool wrappers provide. Shouldn't it work 99.999% of the time? Yes, but the problem is that 0.001% of the time you get failures that may break your data integrity. Anyway, *if* you only use one pool (and *no* other resources), and have at most one connection open per transaction at any time, XA is not really used, and the fact that the pool re-issues the same connection may make the fake XA work 100% of the time. But that really is a special case. Best Regards, Ole Husgaard. P.S: I also think that setting isolation levels per-pool is the right thing to do. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, Bill: |- Somebody had a great idea earlier of adding optimistic locking for |CMP/JAWS. Along with this feature, you could write a specialized |EntityInstanceInterceptor that did not do transactional locking with |commit Option 'A'. This would be great for beans that had |read-only invoked operations 90% of the time. I suggested that and did take the job implementing it (though I actually did no coding yet because I have to earn some money). Marc: yes, that would be interesting, BUT AGAIN I WANT TO FINISH OFF THE 2.X SERIES WITH THE BUGS REMOVED and the streamlined cache with transactional locking. ... WE NEED STABILITY IN FEATURES Yes, agreed. My suggestion was intended for the Rabbit Hole and originally meant to be used with commit options B/C in case there are multiple bean instances when Rabbit Hole is finished. Multiple instances would be not very usefull with pessimistic locking done on the DB, as the pessimistic behaviour (and locking waiting without a message) simply would remain viewed from the clients perspective. But maybe Bill is right, OL could be used with commit option A and single bean instances too? I'm not really sure ... no I don't think so, because then every TX is working on state possibly modified by another TX and, even worse, with one instance only the optimistic approach (based on the diff of the actual beans state and the state before TX.begin) will fail, as at commit time the 'old' state has to be set equal to the current state and the next concurrent TX committing will succeed, where it should see a 'you are too late to commit' exception! regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Georg Rehfeld Sent: Tuesday, June 26, 2001 11:25 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] High load... Hi, Bill: |- Somebody had a great idea earlier of adding optimistic locking for |CMP/JAWS. Along with this feature, you could write a specialized |EntityInstanceInterceptor that did not do transactional locking with |commit Option 'A'. This would be great for beans that had |read-only invoked operations 90% of the time. I suggested that and did take the job implementing it (though I actually did no coding yet because I have to earn some money). Marc: yes, that would be interesting, BUT AGAIN I WANT TO FINISH OFF THE 2.X SERIES WITH THE BUGS REMOVED and the streamlined cache with transactional locking. ... WE NEED STABILITY IN FEATURES Yes, agreed. My suggestion was intended for the Rabbit Hole and originally meant to be used with commit options B/C in case there are multiple bean instances when Rabbit Hole is finished. Multiple instances would be not very usefull with pessimistic locking done on the DB, as the pessimistic behaviour (and locking waiting without a message) simply would remain viewed from the clients perspective. But maybe Bill is right, OL could be used with commit option A and single bean instances too? I'm not really sure ... no I don't think so, because then every TX is working on state possibly modified by another TX and, even worse, with one instance only the optimistic approach (based on the diff of the actual beans state and the state before TX.begin) will fail, as at commit time the 'old' state has to be set equal to the current state and the next concurrent TX committing will succeed, where it should see a 'you are too late to commit' exception! Sorry Georg, I don't what planet I was on when I made the option A with optimistic locking comment. Sort of related, I did a simple test with Oracle 8.1.7 in 2 separate SQL*PLUS windows. With autocommit off, it seems that if you try to update the same row in 2 different windows, one window waits until the other commits. Wonder if this will happen with JDBC as well, I'll let you knowAnybody know the behaviour on this with other DBs? Is this common locking behaviour? If so, great! All in all, I think JBOSS should delegate synching and locking to the DB wherever it can because the DB is usually more efficient at this. Also, IMHO, this is really the best way to synch multiple instances of JBoss. Regards, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
|My suggestion was intended for the Rabbit Hole and originally |meant to be used with commit options B/C in case there are |multiple bean instances when Rabbit Hole is finished. yes, that would be interesting. |Multiple instances would be not very usefull with pessimistic |locking done on the DB, as the pessimistic behaviour (and locking |waiting without a message) simply would remain viewed from the |clients perspective. precisely, I already fought with Vinay the many instances speedup fallacy it's a lie... if you don't break the pessimistic locking at the db then it is useless. |But maybe Bill is right, OL could be used with commit option A |and single bean instances too? I'm not really sure ... no I |don't think so, because then every TX is working on state |possibly modified by another TX and, even worse, with one did he propose that? I don't think so (could be) in any case I am rewriting the cache and one option would have to be a cache that upon looking up an instance if there is a transaction associated with it would clone (deep copy) the current instance so that each tx has a copy IN THE CACHE, this way the container flow is un-affected. Of course that supposes that we rely on the databases to synchronize the updates, for that we need to know that transaction isolation work properly across dbs. btw this is why I am refactoring (rewriting really) the code in there. Well the first reason is to get rid of the busy wait bug, but the nice by product is that you can use the right cache with the right database. I sent a small note yesterday on the transaction isolation... did you guys see it? marcf ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
|Sorry Georg, I don't what planet I was on when I made the option A with |optimistic locking comment. Option A with optimistic locking would be interesting. it is Option A with pessimistic db locking that doesn't really bring anything new. He was criticizing the no copy of the cache for a new transaction. I answered with the clone idea in teh cache. The point is that these are CACHE IMPLEMENTATION dependent, I will make sure the container flow supports these. |Sort of related, I did a simple test with Oracle 8.1.7 in 2 separate |SQL*PLUS windows. With autocommit off, it seems that if you try to update |the same row in 2 different windows, one window waits until the other |commits. Wonder if this will happen with JDBC as well, I'll let you pessimistic then... |knowAnybody know the behaviour on this with other DBs? Is this common |locking behaviour? If so, great! we would have to implement the transaction isolation levels correctly in jboss again I believe that lives at the jbossCMP level. But if we are going to support different vendors for the CMP engines we must take this part out or at least offer a common API... hmmm must think about it. |All in all, I think JBOSS should delegate synching and locking to the DB sure but my point is that can be a cache decision, if you still want to implement a pessimistic cache (like we have right now) with maybe a simple read-only feature then you can. In fact a READ ONLY cache could really improve throughput with copies of the instances for the duration of the transaction. It is then the cache workspace that becomes XA aware... hmmm must think about it. Add-on market??? here we come... we must enable these policies, that is what I am fixing. |wherever it can because the DB is usually more efficient at this. Also, |IMHO, this is really the best way to synch multiple instances of JBoss. hm maybe... maybe not... some will argue that letting all the cache sync on the database is not the best option... it is definitely the *simplest* but certainly not the best.. :) marcf | |Regards, |Bill | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
That is standard locking, you should see that everywhere unless you can set some bit to not wait for locks and just abort the statement. SQL*Plus and JDBC both look the same to the server. Of course with Oracle it won't block readers, with some other databases you will block readers in the second window as well as writers unless you are at the whatever isolation level supports dirty reads. Cheers Jay -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 26, 2001 12:59 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] High load... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Georg Rehfeld Sent: Tuesday, June 26, 2001 11:25 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] High load... Hi, Bill: |- Somebody had a great idea earlier of adding optimistic locking for |CMP/JAWS. Along with this feature, you could write a specialized |EntityInstanceInterceptor that did not do transactional locking with |commit Option 'A'. This would be great for beans that had |read-only invoked operations 90% of the time. I suggested that and did take the job implementing it (though I actually did no coding yet because I have to earn some money). Marc: yes, that would be interesting, BUT AGAIN I WANT TO FINISH OFF THE 2.X SERIES WITH THE BUGS REMOVED and the streamlined cache with transactional locking. ... WE NEED STABILITY IN FEATURES Yes, agreed. My suggestion was intended for the Rabbit Hole and originally meant to be used with commit options B/C in case there are multiple bean instances when Rabbit Hole is finished. Multiple instances would be not very usefull with pessimistic locking done on the DB, as the pessimistic behaviour (and locking waiting without a message) simply would remain viewed from the clients perspective. But maybe Bill is right, OL could be used with commit option A and single bean instances too? I'm not really sure ... no I don't think so, because then every TX is working on state possibly modified by another TX and, even worse, with one instance only the optimistic approach (based on the diff of the actual beans state and the state before TX.begin) will fail, as at commit time the 'old' state has to be set equal to the current state and the next concurrent TX committing will succeed, where it should see a 'you are too late to commit' exception! Sorry Georg, I don't what planet I was on when I made the option A with optimistic locking comment. Sort of related, I did a simple test with Oracle 8.1.7 in 2 separate SQL*PLUS windows. With autocommit off, it seems that if you try to update the same row in 2 different windows, one window waits until the other commits. Wonder if this will happen with JDBC as well, I'll let you knowAnybody know the behaviour on this with other DBs? Is this common locking behaviour? If so, great! All in all, I think JBOSS should delegate synching and locking to the DB wherever it can because the DB is usually more efficient at this. Also, IMHO, this is really the best way to synch multiple instances of JBoss. Regards, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
we would have to implement the transaction isolation levels correctly in jboss again I believe that lives at the jbossCMP level. But if we are going to support different vendors for the CMP engines we must take this part out or at least offer a common API... hmmm must think about it. I added transaction isolation to the new cmp plugin. You can set it by adding the transaction-isolation element after the datasource element. Valid levels are: transaction-none transaction-read-committed transaction-read-uncommitted transaction-repeatable-read transaction-serializable Give me 10 minutes and I'll add it to JAWS... I don't know if you wanted with user configurable, but for now it will allow you to play with different levels. I can make it static later. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
|I added transaction isolation to the new cmp plugin. You can set it by |adding the transaction-isolation element after the datasource element. |Valid levels are: |transaction-none |transaction-read-committed |transaction-read-uncommitted |transaction-repeatable-read |transaction-serializable | |Give me 10 minutes and I'll add it to JAWS... ok but these will be leveraged by new caches in JBoss 3.0 so I would imagine that each application can set its own datasource isolation level, (different kinds of bean). So it IS user configurable right??? Also how does it play with the datasources, if the datasource is shared across applications and different tables support different locking policies (say one table is RO the other RW) can the driver support sequential setIsolationLevel that only applies to the record and or table touched? marcf |I don't know if you wanted with user configurable, but for now it |will allow |you to play with different levels. I can make it static later. | |-dain | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: I don't know if you wanted with user configurable, but for now it will allow you to play with different levels. I can make it static later. static? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Tuesday, June 26, 2001 1:28 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] High load... |Sorry Georg, I don't what planet I was on when I made the option A with |optimistic locking comment. Option A with optimistic locking would be interesting. it is Option A with pessimistic db locking that doesn't really bring anything new. He was criticizing the no copy of the cache for a new transaction. I answered with the clone idea in teh cache. Yeah, I saw your reply to Georg about the deep copying the cache. Good idea... The point is that these are CACHE IMPLEMENTATION dependent, I will make sure the container flow supports these. |Sort of related, I did a simple test with Oracle 8.1.7 in 2 separate |SQL*PLUS windows. With autocommit off, it seems that if you try to update |the same row in 2 different windows, one window waits until the other |commits. Wonder if this will happen with JDBC as well, I'll let you pessimistic then... |knowAnybody know the behaviour on this with other DBs? Is this common |locking behaviour? If so, great! we would have to implement the transaction isolation levels correctly in jboss again I believe that lives at the jbossCMP level. But if we are going to support different vendors for the CMP engines we must take this part out or at least offer a common API... hmmm must think about it. Isolation levels and locking are really orthonogal, aren't they? |All in all, I think JBOSS should delegate synching and locking to the DB sure but my point is that can be a cache decision, if you still want to implement a pessimistic cache (like we have right now) with maybe a simple read-only feature then you can. I still think you should enable the ability to push the pessimistic locking onto the DB with CMP, or onto the developer for BMP. In our app, for instance, we have common, rarely-updated, entities that are shared alot between transactions. Since the current JBoss code-base locks entities into a transaction we are forced to use straight JDBC to avoid the unnecessary locks. I'd really like to avoid mixing JDBC with EJB wherever possible. I guess this should be put off for 3.0 though... In fact a READ ONLY cache could really improve throughput with copies of the instances for the duration of the transaction. It is then the cache workspace that becomes XA aware... hmmm must think about it. Add-on market??? here we come... we must enable these policies, that is what I am fixing. Can't wait to use this stuff |wherever it can because the DB is usually more efficient at this. Also, |IMHO, this is really the best way to synch multiple instances of JBoss. hm maybe... maybe not... some will argue that letting all the cache sync on the database is not the best option... it is definitely the *simplest* but certainly not the best.. :) (This should really be in a separate thread, but...) I really can't see the advantages of synching multiple instances of JBoss without using the DB. Otherwise you'd have to have a lot of expensive network communication between these instances and probably some pretty complex logic as well. The DB is made for this sort of thing, isn't it? Actually, don't bother replying to this, because I really lack the experience to comment on this Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
|Isolation levels and locking are really orthonogal, aren't they? not entirely for example if we decide to NOT lock at the cache level something that the new cache design will allow then you need to make sure that isolation levels are such that you don't corrupt your db. yes the code that locks at the cache level is independent but the data consistency picture requires one or the other to function properly. |I still think you should enable the ability to push the pessimistic locking |onto the DB with CMP, or onto the developer for BMP. In our app, for the new caches will allow that with really configurable caches and locking policies. |instance, we have common, rarely-updated, entities that are shared alot |between transactions. Since the current JBoss code-base locks |entities into |a transaction we are forced to use straight JDBC to avoid the unnecessary |locks. I'd really like to avoid mixing JDBC with EJB wherever possible. I |guess this should be put off for 3.0 though... yes 3.0 (coding it right now) will allow you to specify read-only cache policies, where a copy of the ctx will be enough (no need to copy the instance) |Can't wait to use this stuff no dummy I am saying *I* can't wait for you to write the cache (I will just make sure the container works in all cases, today it doesn't the policy for locking is hardcoded and pessimistic.). The moment you do, feel free to add it to the code base of JBO or sell it for awhile to finance your work and then switch to a real free license (LGPL). | hm maybe... maybe not... some will argue that letting all the | cache sync | on the database is not the best option... it is definitely the *simplest* | but certainly not the best.. :) |(This should really be in a separate thread, but...) I really can't see the |advantages of synching multiple instances of JBoss without using the DB. |Otherwise you'd have to have a lot of expensive network communication |between these instances and probably some pretty complex logic as |well. The |DB is made for this sort of thing, isn't it? Actually, don't bother |replying to this, because I really lack the experience to comment on |this cache design is a bitch... my goal for 3.0 is to provide a DUMB DOWN distributed cache (probably leveraging some JINI technology) will be slow but will work... then we can graduate to oswego cache notifications. Letting the db blindly update the distributed caches through heavy queries is probably not the best use of network and resources. It is the simplest, clearly not the best. In fact now that you mention it, the easiest way to provide the clustering is indeed with a kill of the db by letting it refresh the distributed caches on ejbLoad forced by option B... brain dead but will work tada! clustering v0.0.1 db- jini-oswego-differential multicast marcf |Bill | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
I don't know if you wanted with user configurable, but for now it will allow you to play with different levels. I can make it static later. static? fixed ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi Bill, Sorry Georg, I don't what planet I was on when I made the option A with optimistic locking comment. Oh, might be, you had multiple instances with commit option A in mind? Marc assumed that and seems to be about implementing that. I have to rethink that scenario before commenting on it. I assumed option A = single instance, because the EJB spec 1.1 section 9.1.11 seems to imply this, but then, they tell us: 'These strategies are illustrative, not prescriptive.' Sort of related, I did a simple test with Oracle 8.1.7 in 2 separate SQL*PLUS windows. With autocommit off, it seems that if you try to update the same row in 2 different windows, one window waits until the other commits. Yes, this is expected behaviour with Oracle when both clients actually try to update the same bean/row. With Oracle reading rows without FOR UPDATE ever reads the last committed state without doing ANY locking. When one TX updates, Oracle keeps a modified row copy for that TX, others still may read without locking still seeing the last commited state, but Oracle puts a write lock on the row. When the second TX tries to update, even with my suggested optimistic locking where clause, the update hits that very same row (as the old value for TX2 hasn't changed yet) and must wait for the write lock to be placed. You even can get deadlock situations (I just tested it with SQL*Plus) where Oracle immediately detects it and throws an error to one of the offending TX (which is a good thing, so the TX at least can rollback and let others do their work). I said it before, my suggestion only 'mimickes' optimistic behaviour, real optimistic locking must be done by the DB. To clarify, when my suggested OL where clause is usefull and when not: TX 1TX 2 read row A update A read row A -- still gets old state commit update A -- will fail with 'too late' TX 1TX 2 read row A read row A update A update A -- will wait for lock time passes . commit ^ +-- will fail with 'too late' TX 1TX 2 read row A read row B update A update B read row B -+- will get old state as seen | by other TX before the update read row A -+ update A will wait for lock update B Oracle will immediately detect dead lock and break it by SQL error: ORA-00060: deadlock detected while waiting for resource to one of the TX Wonder if this will happen with JDBC as well, I'll let you know For sure! Anybody know the behaviour on this with other DBs? Is this common locking behaviour? If so, great! There seem to be DBs out, that can do real optimistic locking, someone mentioned that. But for many others (i.e. Informix) it depends on the isolation level, Marc hinted us already twice (please note, my Informix knowledge is somewhat oldfashioned, I kicked it out years ago for this (and other) stupid behaviour): There are 4 Informix isolation levels: low dirty read = ANSI read uncommitted medium committed read = ANSI read committed medium cursor stability highrepeatable read = ANSI repeatable read, ANSI serializable With isolation level set to 'dirty read' Informix doesn't set locks when reading, but it shows UNCOMMITTED changes done by other TXs to you (phantom rows)!! It simply ignores locks at all. This isolation level is useless for multi TX serious work altogether. 'committed read' is documented as not setting locks when reading rows and only retrieving committed rows. So this sounds to be the right isolation to use for the OL approach. But when I remember right, it actually BLOCKS reading rows that are updated, but uncommitted by another TX. Some Informix guru here to correct me? If I'm right, this still remains the level to use, but with havy loaded Server/DB the concurrency will drop to only let the updating TX proceed, blocking out most read only access. 'cursor stability' is very similar to 'committed read' except that it places a shared lock (preventing others from updating) on the row under the cursor, not very usefull for our scenario, where the JDBC driver processes the query completely or in pages shifting that lock from row to row with read-ahead; with commit option B/C and no read ahead this at best resembles to pessimistic locking or is no difference to 'committed read'. 'repeatable read' places shared locks on ALL rows read, preventing every modification to them. Lacks the same concurrency problem when there are uncommited changed rows to read. For the OL suggestion we won't
Re: [JBoss-dev] High load...
I don't know if you wanted with user configurable, but for now it will allow you to play with different levels. I can make it static later. static? fixed Like at compile time, literally 'static' in the java sense static? Please god, not this again. Remember that the people responsible for care and feeding of JBoss server instances are liable to be system administrators who have just about 0 regard for products that require a recompile just to change a setting. Consider all the neat stuff you can change by catting some value into a psuedo-file under /proc on a linux box. Consider the things people bitch about _not_ being able to change there (per-user process limit, etc.). Relax dan, I was implying that if we needed to only support one isolation level, because of a cache configuration, I can remove the user-configurable part and set it to always be one isolation level. This is all moot because I think I will be rolling back the change (read my other message). -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, On 2001.06.26 11:24:43 -0400 Georg Rehfeld wrote: snip But maybe Bill is right, OL could be used with commit option A and single bean instances too? I'm not really sure ... no I don't think so, because then every TX is working on state possibly modified by another TX and, even worse, with one instance only the optimistic approach (based on the diff of the actual beans state and the state before TX.begin) will fail, as at commit time the 'old' state has to be set equal to the current state and the next concurrent TX committing will succeed, where it should see a 'you are too late to commit' exception! I don't think I understand what you are suggesting. However... Are you familiar with the lock-free versioning/ optimistic locking scheme used in interbase/firebird? transactions are numbered sequentially when they are started. Each record (version) includes the transaction id of the last change to it. When you query information (within a transaction), you get the record version with the largest transaction id = your transaction id. When you change a record, a new version is put in the db with your transaction id ( of course no one else can see it till you commit). The older versions hang around until no transactions are active that could see them, then they are garbage collected. There is a transaction property that determines behavior when two transactions try to modify the same record: either you get an immediate exception or your changes block until the other guy commits (you get an exception) or rolls back (your transaction succeeds) Note that this results in snapshot transaction isolation rather than read committed. (I don't know how read committed is implemented, and don't know why you would want to use it). I confess I don't quite understand how snapshot differs from serializable isolation -- its certainly close. This requires a version for each modifying transaction, rather than a single version or a version for each transaction. You may need to keep several committed versions around at once until all transactions referencing them are complete. I think you could use a scheme like this at least with commit option A. david jencks regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, Forgive me if I am talking nonsense, but doesn't it only make sense to have transaction isolation per transaction I very much doubt you will find a db that can support several transaction isolation levels within one transaction. I can't quite figure out what it would mean, either. So I say, put it with the transaction requirements for methods - Requires, Requires New, etc. Then you can set the isolation each time you start a new transaction, based on this specification. david jencks On 2001.06.26 14:48:00 -0400 Dain Sundstrom wrote: |I added transaction isolation to the new cmp plugin. You can set it by |adding the transaction-isolation element after the datasource element. |Valid levels are: |transaction-none |transaction-read-committed |transaction-read-uncommitted |transaction-repeatable-read |transaction-serializable | |Give me 10 minutes and I'll add it to JAWS... ok but these will be leveraged by new caches in JBoss 3.0 so I would imagine that each application can set its own datasource isolation level, (different kinds of bean). So it IS user configurable right??? Also how does it play with the datasources, if the datasource is shared across applications and different tables support different locking policies (say one table is RO the other RW) can the driver support sequential setIsolationLevel that only applies to the record and or table touched? marcf Right now this the jaws and jbosscmp code only support datasource per application. When we implement datasource per bean, we can have isolation level per bean. This leads to the intresting situation with EJB-QL queries that thouch multiput beans. May be we need to specify an isolation lever for each query. Havn't thought about it much. Right now you can only set it for the entire ejb-jar. Just tell me when you get the cache stuff figgured out and I can update jaws and jbosscmp to support what ever you want. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
|I don't think I understand what you are suggesting. However... | |Are you familiar with the lock-free versioning/ optimistic locking scheme |used in interbase/firebird? | |transactions are numbered sequentially when they are started. | |Each record (version) includes the transaction id of the last change to it. | |When you query information (within a transaction), you get the record |version with the largest transaction id = your transaction id. yes ! this is what I asked for a couple of weeks ago, on a suggestion by Farid of CPW (Vinay's collegue), versioning the records for long running transactions and optimistic locking with distributions that have low rw MAKES TOTAL SENSE. However we can do it at the container level, not even at the db level marcf ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
David Jencks wrote: Read on - the problem with this occured to a few of us already. Although none of us mentioned putting it in the container-transaction - that's interesting. But what if a method at iso 'read-uncommitted' calls a method in an iso 'serializable' transaction? thanks, danch Hi, Forgive me if I am talking nonsense, but doesn't it only make sense to have transaction isolation per transaction I very much doubt you will find a db that can support several transaction isolation levels within one transaction. I can't quite figure out what it would mean, either. So I say, put it with the transaction requirements for methods - Requires, Requires New, etc. Then you can set the isolation each time you start a new transaction, based on this specification. david jencks On 2001.06.26 14:48:00 -0400 Dain Sundstrom wrote: |I added transaction isolation to the new cmp plugin. You can set it by |adding the transaction-isolation element after the datasource element. |Valid levels are: |transaction-none |transaction-read-committed |transaction-read-uncommitted |transaction-repeatable-read |transaction-serializable | |Give me 10 minutes and I'll add it to JAWS... ok but these will be leveraged by new caches in JBoss 3.0 so I would imagine that each application can set its own datasource isolation level, (different kinds of bean). So it IS user configurable right??? Also how does it play with the datasources, if the datasource is shared across applications and different tables support different locking policies (say one table is RO the other RW) can the driver support sequential setIsolationLevel that only applies to the record and or table touched? marcf Right now this the jaws and jbosscmp code only support datasource per application. When we implement datasource per bean, we can have isolation level per bean. This leads to the intresting situation with EJB-QL queries that thouch multiput beans. May be we need to specify an isolation lever for each query. Havn't thought about it much. Right now you can only set it for the entire ejb-jar. Just tell me when you get the cache stuff figgured out and I can update jaws and jbosscmp to support what ever you want. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
I disagreewell, at least for our app, we have transactions where some entities really need to be serialized and other entities within the transaction are just fine with read_committed. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Tuesday, June 26, 2001 4:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] High load... Hi, Forgive me if I am talking nonsense, but doesn't it only make sense to have transaction isolation per transaction I very much doubt you will find a db that can support several transaction isolation levels within one transaction. I can't quite figure out what it would mean, either. So I say, put it with the transaction requirements for methods - Requires, Requires New, etc. Then you can set the isolation each time you start a new transaction, based on this specification. david jencks On 2001.06.26 14:48:00 -0400 Dain Sundstrom wrote: |I added transaction isolation to the new cmp plugin. You can set it by |adding the transaction-isolation element after the datasource element. |Valid levels are: |transaction-none |transaction-read-committed |transaction-read-uncommitted |transaction-repeatable-read |transaction-serializable | |Give me 10 minutes and I'll add it to JAWS... ok but these will be leveraged by new caches in JBoss 3.0 so I would imagine that each application can set its own datasource isolation level, (different kinds of bean). So it IS user configurable right??? Also how does it play with the datasources, if the datasource is shared across applications and different tables support different locking policies (say one table is RO the other RW) can the driver support sequential setIsolationLevel that only applies to the record and or table touched? marcf Right now this the jaws and jbosscmp code only support datasource per application. When we implement datasource per bean, we can have isolation level per bean. This leads to the intresting situation with EJB-QL queries that thouch multiput beans. May be we need to specify an isolation lever for each query. Havn't thought about it much. Right now you can only set it for the entire ejb-jar. Just tell me when you get the cache stuff figgured out and I can update jaws and jbosscmp to support what ever you want. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
|I disagreewell, at least for our app, we have transactions where some |entities really need to be serialized and other entities within the |transaction are just fine with read_committed. we will need to express this in code, but there are really 2 levels of synchronization that need to happen. One is the db, one is the container cache*s*.. the db will isolate the transaction very well, and provide read bla bla at the connection level, whether the drivers support it and whether it is the same consequences on all dbs is to be seen but that is a way. We can also do read only beans in cache that would REALLY speed things up (no need to always reload no need to go to the DB AT ALL, except the first time we get in cache) and that is very configurable, as low as we want. 2 different things, same result isolation, one is superior in throughput and management, marcf | |Bill | | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]On Behalf Of David | Jencks | Sent: Tuesday, June 26, 2001 4:43 PM | To: [EMAIL PROTECTED] | Subject: Re: [JBoss-dev] High load... | | | Hi, | | Forgive me if I am talking nonsense, but doesn't it only make | sense to have | transaction isolation per transaction I very much doubt you |will find | a db that can support several transaction isolation levels within one | transaction. I can't quite figure out what it would mean, either. So I | say, put it with the transaction requirements for methods - Requires, | Requires New, etc. Then you can set the isolation each time you start a | new transaction, based on this specification. | | david jencks | | On 2001.06.26 14:48:00 -0400 Dain Sundstrom wrote: | |I added transaction isolation to the new cmp plugin. You can | set it by | |adding the transaction-isolation element after the datasource | element. | |Valid levels are: | |transaction-none | |transaction-read-committed | |transaction-read-uncommitted | |transaction-repeatable-read | |transaction-serializable | | | |Give me 10 minutes and I'll add it to JAWS... | | ok but these will be leveraged by new caches in JBoss 3.0 | | | | so I would imagine that each application can set its own datasource | isolation level, (different kinds of bean). So it IS user | configurable | right??? | | Also how does it play with the datasources, if the datasource | is shared | across applications and different tables support different locking | policies | (say one table is RO the other RW) can the driver support sequential | setIsolationLevel that only applies to the record and or table | touched? | marcf | | | Right now this the jaws and jbosscmp code only support datasource per | application. When we implement datasource per bean, we can have | isolation | level per bean. This leads to the intresting situation with EJB-QL | queries | that thouch multiput beans. May be we need to specify an |isolation lever | for | each query. Havn't thought about it much. Right now you can | only set it | for the entire ejb-jar. | | Just tell me when you get the cache stuff figgured out and I can update | jaws | and jbosscmp to support what ever you want. | | -dain | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | http://lists.sourceforge.net/lists/listinfo/jboss-development | | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | http://lists.sourceforge.net/lists/listinfo/jboss-development | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
|But if they're in the same transaction, they must use the same isolation |level - per our discussion on the database doing an implicite commit |when you try to change levels. I don't think it makes logical sense to |talk about having two different transaction isolation levels in the same |transaction, either - either the transaction is serializable or the |transaction is read-committed. why not? the STATE is read-committed or not, meaning that a theoretical level I have no problem saying that a transaction can encompass beans that are read-only (most of them, like a calendar and a whachamakalit list of stuff (menu) from where you select your products taht doesn't change (catalog?)) but the order would of course be read write. For design reasons I might want to use the global transaction to emcompass the records and have different isolations on their state. You don't agree? marcf | |-danch | |Bill Burke wrote: | | I disagreewell, at least for our app, we have transactions where some | entities really need to be serialized and other entities within the | transaction are just fine with read_committed. | | Bill | | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Jencks |Sent: Tuesday, June 26, 2001 4:43 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] High load... | | |Hi, | |Forgive me if I am talking nonsense, but doesn't it only make |sense to have |transaction isolation per transaction I very much doubt you |will find |a db that can support several transaction isolation levels within one |transaction. I can't quite figure out what it would mean, either. So I |say, put it with the transaction requirements for methods - Requires, |Requires New, etc. Then you can set the isolation each time you start a |new transaction, based on this specification. | |david jencks | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, since you can't change the transaction isolation after you start the transaction, the isolation is determined by the outermost isolation specifier. david jencks On 2001.06.26 16:47:16 -0400 danch (Dan Christopherson) wrote: David Jencks wrote: Read on - the problem with this occured to a few of us already. Although none of us mentioned putting it in the container-transaction - that's interesting. But what if a method at iso 'read-uncommitted' calls a method in an iso 'serializable' transaction? thanks, danch Hi, Forgive me if I am talking nonsense, but doesn't it only make sense to have transaction isolation per transaction I very much doubt you will find a db that can support several transaction isolation levels within one transaction. I can't quite figure out what it would mean, either. So I say, put it with the transaction requirements for methods - Requires, Requires New, etc. Then you can set the isolation each time you start a new transaction, based on this specification. david jencks On 2001.06.26 14:48:00 -0400 Dain Sundstrom wrote: |I added transaction isolation to the new cmp plugin. You can set it by |adding the transaction-isolation element after the datasource element. |Valid levels are: |transaction-none |transaction-read-committed |transaction-read-uncommitted |transaction-repeatable-read |transaction-serializable | |Give me 10 minutes and I'll add it to JAWS... ok but these will be leveraged by new caches in JBoss 3.0 so I would imagine that each application can set its own datasource isolation level, (different kinds of bean). So it IS user configurable right??? Also how does it play with the datasources, if the datasource is shared across applications and different tables support different locking policies (say one table is RO the other RW) can the driver support sequential setIsolationLevel that only applies to the record and or table touched? marcf Right now this the jaws and jbosscmp code only support datasource per application. When we implement datasource per bean, we can have isolation level per bean. This leads to the intresting situation with EJB-QL queries that thouch multiput beans. May be we need to specify an isolation lever for each query. Havn't thought about it much. Right now you can only set it for the entire ejb-jar. Just tell me when you get the cache stuff figgured out and I can update jaws and jbosscmp to support what ever you want. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, David Jencks: I don't think I understand what you are suggesting. However... Just as a reminder, my suggestions for mimicked optimistic locking was: generate SQL for update/delete with a where clause not only using the primary key fields, but also the old values of changed fields / all fields; then interpret a '0 rows affected' response from executeUpdate() as you're to late, you must rollback and throw an Exception. Are you familiar with the lock-free versioning/ optimistic locking scheme used in interbase/firebird? transactions are numbered sequentially when they are started. I know, someone mentioned it before. Interbase does that at the database level, I assume, no need to have the TX ID in the EJB server/container/bean? My suggestion is meant for DB's, that don't have native optimistic locking support (and only mimickes OL, see one of my last mails with the diagram, showing pitfalls). I also originally considered 'versioning', but this whould require a persistet version number in every table, possibly not a good option for existing DB's or tables with very few columns and very much rows, because of the size overhead. you get an immediate exception or your changes block until the other guy commits (you get an exception) or rolls back (your transaction succeeds) As you may have seen from the diagram already, the first option is impossible with my approach due to the DB really locking on updates, it ever behaves as with the second option above. I think you could use a scheme like this at least with commit option A. Hmmm, I'm still unsure, if commit option A, multiple instances and locking play nicely together, need more time to consider different scenarios, I already said, I'm too slow thinking :-) Thanks and regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
Why can't a transaction manage different resources and each of those resources use a different transaction-isolation level? What's wrong with that? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Tuesday, June 26, 2001 5:38 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] High load... Hi, since you can't change the transaction isolation after you start the transaction, the isolation is determined by the outermost isolation specifier. david jencks On 2001.06.26 16:47:16 -0400 danch (Dan Christopherson) wrote: David Jencks wrote: Read on - the problem with this occured to a few of us already. Although none of us mentioned putting it in the container-transaction - that's interesting. But what if a method at iso 'read-uncommitted' calls a method in an iso 'serializable' transaction? thanks, danch Hi, Forgive me if I am talking nonsense, but doesn't it only make sense to have transaction isolation per transaction I very much doubt you will find a db that can support several transaction isolation levels within one transaction. I can't quite figure out what it would mean, either. So I say, put it with the transaction requirements for methods - Requires, Requires New, etc. Then you can set the isolation each time you start a new transaction, based on this specification. david jencks On 2001.06.26 14:48:00 -0400 Dain Sundstrom wrote: |I added transaction isolation to the new cmp plugin. You can set it by |adding the transaction-isolation element after the datasource element. |Valid levels are: |transaction-none |transaction-read-committed |transaction-read-uncommitted |transaction-repeatable-read |transaction-serializable | |Give me 10 minutes and I'll add it to JAWS... ok but these will be leveraged by new caches in JBoss 3.0 so I would imagine that each application can set its own datasource isolation level, (different kinds of bean). So it IS user configurable right??? Also how does it play with the datasources, if the datasource is shared across applications and different tables support different locking policies (say one table is RO the other RW) can the driver support sequential setIsolationLevel that only applies to the record and or table touched? marcf Right now this the jaws and jbosscmp code only support datasource per application. When we implement datasource per bean, we can have isolation level per bean. This leads to the intresting situation with EJB-QL queries that thouch multiput beans. May be we need to specify an isolation lever for each query. Havn't thought about it much. Right now you can only set it for the entire ejb-jar. Just tell me when you get the cache stuff figgured out and I can update jaws and jbosscmp to support what ever you want. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
|Why can't a transaction manage different resources and each of those |resources use a different transaction-isolation level? What's wrong with |that? imho nothing marcf ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Bill Burke wrote: Why can't a transaction manage different resources and each of those resources use a different transaction-isolation level? What's wrong with that? If different resources == different DB connections, i suppose it could. Maybe. But I keep thinking of the isolation level as an attribute of the transaction itself. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, Bill Burke: Why can't a transaction manage different resources and each of those resources use a different transaction-isolation level? What's wrong with that? There is nothing wrong with the idea IMHO. As I told earlier, some DB's (Informix) actually can do such isolation level switching inside a transaction. ANSI seems to not support that and so there might be DBs out, that follow ANSI and can't do it (or even worse, do an implicit commit). And the EJB specs seem to not like it, considering the least advanced common behaviour. No need for us, to do it better (and warn the user, that it is possibly not portable to other EJB servers, but who would wan't that anyway :-) (Ok, just kidding). regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
marc fleury wrote: |But if they're in the same transaction, they must use the same isolation |level - per our discussion on the database doing an implicite commit |when you try to change levels. I don't think it makes logical sense to |talk about having two different transaction isolation levels in the same |transaction, either - either the transaction is serializable or the |transaction is read-committed. why not? the STATE is read-committed or not, meaning that a theoretical level I have no problem saying that a transaction can encompass beans that are read-only (most of them, like a calendar and a whachamakalit list of stuff (menu) from where you select your products taht doesn't change (catalog?)) but the order would of course be read write. For design reasons I might want to use the global transaction to emcompass the records and have different isolations on their state. You don't agree? marcf I'm thinking of the isolation level as an immutable part of the transaction - partly because this is how the databases implement it (at least as far as JDBC goes). Sure, it would be useful to be able to specify different levels per bean, but given the apparent constraints that the databases are putting us under, implementing it against the database isn't feasable. Now, if we do move the notion of isolation level into the container further (which I think we've both mentioned) so that we can get the cache's et. al. helping us out, then I can certainly agree with your 'theoretical' case. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi, David Jencks wrote: Yes, I was trying to point out that interbase/firebird has been doing this successfully for 15 years, we can have our container do it too, here's an algorithm you left out the most interesting: the algorithm! Please forward! Someone mentioned that there might be dbs using optimistic locking: interbase/firebird is one such. :-) As an aside, this versioning idea of Jim Starkey is the reason interbase/firebird exists. It allows a production database to generate meaningful reports: the report runs in a transaction that only sees the data present when the report started, yet production transactions can freely modify all the data in the db without affecting the report. This is the same with Oracle (one reason Oracle exists and still is one of the marked leaders :-). Note, that I'm not affiliated with Oracle in any way. Just used it the last 13 years (and other DBs as well, went back to Oracle most of the time). Oracle calls this 'read consistency' and at the lowest possible level only reads committed data and returns only data as of the time the query started, even when the read would need hours to complete and without hindering any other TX to update freely (including deleting ALL rows from the table). At that lowest level, this is not repeatable, the next same query then sees the data as of the new query start time, but there is a setting to do it repeatabe (which then USES locks, whereas the default behaviour is lock free). regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of danch Sent: Tuesday, June 26, 2001 6:31 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] High load... marc fleury wrote: |But if they're in the same transaction, they must use the same isolation |level - per our discussion on the database doing an implicite commit |when you try to change levels. I don't think it makes logical sense to |talk about having two different transaction isolation levels in the same |transaction, either - either the transaction is serializable or the |transaction is read-committed. why not? the STATE is read-committed or not, meaning that a theoretical level I have no problem saying that a transaction can encompass beans that are read-only (most of them, like a calendar and a whachamakalit list of stuff (menu) from where you select your products taht doesn't change (catalog?)) but the order would of course be read write. For design reasons I might want to use the global transaction to emcompass the records and have different isolations on their state. You don't agree? marcf I'm thinking of the isolation level as an immutable part of the transaction - partly because this is how the databases implement it (at least as far as JDBC goes). Sure, it would be useful to be able to specify different levels per bean, but given the apparent constraints that the databases are putting us under, implementing it against the database isn't feasable. Just use a freakin' different connection pool for different beans and there is no freakin' database constraint. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
Hi, Ok, I was thinking of within one db. I'm working on a logical inconsistency example if you change isolation within one db, but I don't have it yet. I agree, if you have a loosely coupled distributed transaction, even on one resource manager, the different branches can have different isolation levels with no problems. Do you have a suggestion for a declarative isolation specification that will result in one isolation level/transaction-branch and be simpler than using bmt? So far I can't think of one. flame-baitI tend to think perhaps the best solution is to use a db that gives you snapshot isolation with no performance penalty/flame-bait although perhaps this is not always possible. david jencks On 2001.06.26 17:49:42 -0400 Bill Burke wrote: Why can't a transaction manage different resources and each of those resources use a different transaction-isolation level? What's wrong with that? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Tuesday, June 26, 2001 5:38 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] High load... Hi, since you can't change the transaction isolation after you start the transaction, the isolation is determined by the outermost isolation specifier. david jencks On 2001.06.26 16:47:16 -0400 danch (Dan Christopherson) wrote: David Jencks wrote: Read on - the problem with this occured to a few of us already. Although none of us mentioned putting it in the container-transaction - that's interesting. But what if a method at iso 'read-uncommitted' calls a method in an iso 'serializable' transaction? thanks, danch Hi, Forgive me if I am talking nonsense, but doesn't it only make sense to have transaction isolation per transaction I very much doubt you will find a db that can support several transaction isolation levels within one transaction. I can't quite figure out what it would mean, either. So I say, put it with the transaction requirements for methods - Requires, Requires New, etc. Then you can set the isolation each time you start a new transaction, based on this specification. david jencks On 2001.06.26 14:48:00 -0400 Dain Sundstrom wrote: |I added transaction isolation to the new cmp plugin. You can set it by |adding the transaction-isolation element after the datasource element. |Valid levels are: |transaction-none |transaction-read-committed |transaction-read-uncommitted |transaction-repeatable-read |transaction-serializable | |Give me 10 minutes and I'll add it to JAWS... ok but these will be leveraged by new caches in JBoss 3.0 so I would imagine that each application can set its own datasource isolation level, (different kinds of bean). So it IS user configurable right??? Also how does it play with the datasources, if the datasource is shared across applications and different tables support different locking policies (say one table is RO the other RW) can the driver support sequential setIsolationLevel that only applies to the record and or table touched? marcf Right now this the jaws and jbosscmp code only support datasource per application. When we implement datasource per bean, we can have isolation level per bean. This leads to the intresting situation with EJB-QL queries that thouch multiput beans. May be we need to specify an isolation lever for each query. Havn't thought about it much. Right now you can only set it for the entire ejb-jar. Just tell me when you get the cache stuff figgured out and I can update jaws and jbosscmp to support what ever you want. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Tuesday, June 26, 2001 6:57 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] High load... Hi, Ok, I was thinking of within one db. I'm working on a logical inconsistency example if you change isolation within one db, but I don't have it yet. I agree, if you have a loosely coupled distributed transaction, even on one resource manager, the different branches can have different isolation levels with no problems. Do you have a suggestion for a declarative isolation specification that will result in one isolation level/transaction-branch and be simpler than using bmt? So far I can't think of one. Yes, 1. Make JDBC transaction isolation level configurable for connection pools. 2. Create a connection pool for READ_COMMITTED 3. Create a connection pool for SERIALIZED 4. Attach your CMP/CMT entity to the desired pool Am I making sense? Is this what you're asking for? Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi Marc Fleury wrote: precisely, I already fought with Vinay the many instances speedup fallacy it's a lie... if you don't break the pessimistic locking at the db then it is useless. so this puts more stress on me to implement it, as it is usefull already with multiple server instances. I still can't promise to start that before next weekend. |But maybe Bill is right, OL could be used with commit option A |and single bean instances too? I'm not really sure ... no I |don't think so, because then every TX is working on state |possibly modified by another TX and, even worse, with one did he propose that? I don't think so (could be) in any case I am rewriting the cache and one option would have to be a cache that upon looking up an instance if there is a transaction associated with it would clone (deep copy) the current instance so that each tx has a copy IN THE CACHE, this way the container flow is un-affected. If I understand you right, you would keep an unmodified original and give every TX a clone of that, right? As cloning, when the second TX comes in, would be too late, the cached instance could already been modified and then rolled back. Non TX threads get what, the original? Or better a clobber this when you don't know what you are doing clone handed out to every thread outside TX? Of course that supposes that we rely on the databases to synchronize the updates, for that we need to know that transaction isolation work properly across dbs. Not sure what you mean here, several DBs in same TX? Nevertheless I think the multiple instances cache would nicely fit together with the optimisting locking, wether it is naturally done by the DB or mimicked on top of pessimistic locking DBs (the latter having some pitfalls, see my earlier message with the diagram). Though I can't come up yet with a scenario where this will fail, why does the EJB spec 1.1 section 9.1.11 suggest a correspondence between commit option A and single bean instances? Does someone have a hint? btw this is why I am refactoring (rewriting really) the code in there. Well the first reason is to get rid of the busy wait bug, Really happy about that! but the nice by product is that you can use the right cache with the right database. I sent a small note yesterday on the transaction isolation... did you guys see it? yes, as you already might have seen from my other messages. regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Hi who ever it was, said: I'm thinking of the isolation level as an immutable part of the transaction - partly because this is how the databases implement it (at least as far as JDBC goes). Sure, it would be useful to be able to specify different levels per bean, but given the apparent constraints that the databases are putting us under, implementing it against the database isn't feasable. Bill Burke answered: Just use a freakin' different connection pool for different beans and there is no freakin' database constraint. That would cause a problem with transactions and not XA compliant JDBC drivers, wouldn't it? The reason why JBoss pool pickes a connection from the pool based on the TX (reuses a connection with a TX when another connection is requested in the same TX) is, because current drivers often have a one to one correspondence between connection and transaction (as of comments in JBoss pool). As a result, when you wanted to switch isolation inside one TX the CMP code had to issue 'SET ISOLATION whatever' (or similar syntax for non Informix DBs), the JDBC call setTransactionIsolation() most probably can't be used, as it seems to behave ANSI like (does not allow switching inside a TX as of java.sql.Connection docs). regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Georg Rehfeld Sent: Tuesday, June 26, 2001 8:17 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] High load... Hi who ever it was, said: I'm thinking of the isolation level as an immutable part of the transaction - partly because this is how the databases implement it (at least as far as JDBC goes). Sure, it would be useful to be able to specify different levels per bean, but given the apparent constraints that the databases are putting us under, implementing it against the database isn't feasable. Bill Burke answered: Just use a freakin' different connection pool for different beans and there is no freakin' database constraint. That would cause a problem with transactions and not XA compliant JDBC drivers, wouldn't it? The reason why JBoss pool pickes a connection from the pool based on the TX (reuses a connection with a TX when another connection is requested in the same TX) is, because current drivers often have a one to one correspondence between connection and transaction (as of comments in JBoss pool). 2 entity beans. 2 connection pools(but same database), each connection pool is configured to use a certain JDBC isolation level. Entity 1 is attach to pool 1, Entity 2 is attached to pool 2. 1. Start JBoss transaction 2. Access Entity1. A connection is grabbed from pool 1, connection1.setIsolation(blah blah), 3. access entity2. A connection is created from pool 2, connection2.setIsolation(blah blah) 4. End JBoss transaction. commit is called on connection 1 and connection 2. This should work, shouldn't it? Regards, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
| Sure, it would be useful to be able to specify different levels per | bean, but given the apparent constraints that the databases are putting | us under, implementing it against the database isn't feasable. | | |Just use a freakin' different connection pool for different beans and there |is no freakin' database constraint. oh wait reading old stuff, so you are saying that (do jdbc connection support setIsolationlevel on the fly) == false shit... databases is an UGLY world, you know what??? we can do MUCH better at the distributed cache level so screw delegating to the db... I am drunk and it is getting tough to think ... marcf ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
Talking about pools, While looking at the ASF stuff, it looks like every depolyed MDB gets it's own Thread Pool.. I have a feeling that this is NOT how it's soposed to be. Regards, Hiram From: marc fleury [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] High load... Date: Tue, 26 Jun 2001 23:30:32 -0400 |2 entity beans. 2 connection pools(but same database), each connection pool |is configured to use a certain JDBC isolation level. Entity 1 is attach to |pool 1, Entity 2 is attached to pool 2. yuck... I still don't have a clear answer to what we do = (does a jdbc connection support setting isolations level on the fly)? we use one pool and the container sets levels : we are stuck with many pools marcf PS: of course many pools works but yuck! | |1. Start JBoss transaction |2. Access Entity1. A connection is grabbed from pool 1, |connection1.setIsolation(blah blah), |3. access entity2. A connection is created from pool 2, |connection2.setIsolation(blah blah) |4. End JBoss transaction. commit is called on connection 1 and connection |2. | |This should work, shouldn't it? | |Regards, | |Bill | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
I think you missed one of the old messages (way to many today). It appears that if you changes the transaction isolation in the middle of a transaction the driver can perform an implicit commit (YUCK). So, I don't think we can trust drivers to allows us to change the level on the fly. -dain - Original Message - From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 26, 2001 10:36 PM Subject: RE: [JBoss-dev] High load... | Sure, it would be useful to be able to specify different levels per | bean, but given the apparent constraints that the databases are putting | us under, implementing it against the database isn't feasable. | | |Just use a freakin' different connection pool for different beans and there |is no freakin' database constraint. oh wait reading old stuff, so you are saying that (do jdbc connection support setIsolationlevel on the fly) == false shit... databases is an UGLY world, you know what??? we can do MUCH better at the distributed cache level so screw delegating to the db... I am drunk and it is getting tough to think ... marcf ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
|I think you missed one of the old messages (way to many today). | |It appears that if you changes the transaction isolation in the middle of a |transaction the driver can perform an implicit commit (YUCK). | |So, I don't think we can trust drivers to allows us to change the level on |the fly. well that is EXCELLENT NEWS... ? you are saying that I can actually change the isolation level on a jdbc connection for a new transaction ? ( I don't want to change in the middle) what I want to do is connection A gets assigned to transaction B transaction B encompasses bean C The container gets connection D Connection D was use with bean E previously bean C is ISOLATION1 and D is ISOLATION2 my question is can we reconfigure connection D with the new stuff? you seem to say that yes...because you are aware of problems that arise if we do it INSIDE a transaction, when I really don't care about this fine a feature... marcf | |-dain |- Original Message - |From: marc fleury [EMAIL PROTECTED] |To: [EMAIL PROTECTED] |Sent: Tuesday, June 26, 2001 10:36 PM |Subject: RE: [JBoss-dev] High load... | | | | Sure, it would be useful to be able to specify different levels per | | bean, but given the apparent constraints that the databases |are putting | | us under, implementing it against the database isn't feasable. | | | | | |Just use a freakin' different connection pool for different beans and |there | |is no freakin' database constraint. | | oh wait reading old stuff, so you are saying that | | (do jdbc connection support setIsolationlevel on the fly) == false | | shit... | | databases is an UGLY world, you know what??? we can do MUCH better at the | distributed cache level so screw delegating to the db... | | I am drunk and it is getting tough to think ... | | marcf | | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | http://lists.sourceforge.net/lists/listinfo/jboss-development | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
|You should try this on some other OSes. I believe that the sun vm on linux |uses a one-to-one mode (one java thread to one native thread). This model |has problems with thread contension becase all thread contension |is resolved |in the kernel which has to pass through the native layer. Other OSes have I will try that on windows 2000, I will commit the code soon, |I think the important question is Why do we have a passivation |cache? Why |did we add it and is the circumstances that led us to add it still |valid. I |often find optimiztions in my client's code for situations that simply are |not a problem any more. Optimizations make code more difficult to read and |therefore maintian. (By the way, we could make a arument along |the lines of |scaleability vs. performance of a single instance) | |I am all for making the code as simple a possible, as I said the simpler design is with nopassivation stuff in it. I believe with gig ram machines floating around you can carefully design your deployment so that you will never need passivation. I will try to keep it in but seriously need to revisit that code, I will take a couple of days of rabbit hole (paid time) to try and streamline it, it is key to the scalability and speed of execution On the other hand it seems to be pretty robust, I can't say I have BROKEN it ;-) which is good news marcf | |-dain | | |- Original Message - |From: marc fleury [EMAIL PROTECTED] |To: Jboss-Development@Lists. Sourceforge. Net |[EMAIL PROTECTED] |Sent: Monday, June 25, 2001 11:17 AM |Subject: [JBoss-dev] High load... | | | I am about to commit an MBean / EJB pair whose only purpose in life is to | stress the cache locking logic. | | Because it is an MBean it never goes through the RMI layers and so we are | seeing RAW performance of the logic that does the thread mutex semaphore |and | all taht... that was the part I had to optimize when I went to SUN... now | with the new logic 50 threads all pinging on 1 object. | | on my new athlon it crawls to an halt at 50 clients in parallel |(they wait | 100ms before pinging again) and there is almost no invocation going | through... | | :( | | anybody ELSE seen this? I am almost leaning towards TOTALLY removing the | passivating caches and associated mutex logic as is | | Ok I will say the word... this is shite ... | | or is it just me? | | marcf | | _ | Marc Fleury, Ph.D | [EMAIL PROTECTED] | _ | | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | http://lists.sourceforge.net/lists/listinfo/jboss-development | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
On Monday 25 June 2001 18:50, you wrote: |You should try this on some other OSes. I believe that the sun vm on | linux uses a one-to-one mode (one java thread to one native thread). | This model has problems with thread contension becase all thread | contension |is resolved |in the kernel which has to pass through the native layer. Other OSes have I will try that on windows 2000, I will commit the code soon, marcf The Volano report has some numbers (performance and network scalability) which can give an idea of the different JVM's on various OS'es. http://www.volano.com/report/index.html Cheers, Jesper ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
|Will this affect commit Option A and B, which doesn't passivate? I'm not true. Even under option A if you are under heavy load, the cache can passivate under you. marcf |curious because in the new cmp stuff, I delete my persistence context on |passivation. The persistence context is where I store the cmp 2.x |cmp field |data. So, when a bean is passivated I assume that I have to |reload the data |from the db. I can work arround this if the assumtion won't hold anymore. | |-dain | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
on 1-06-25 18.39, Dain Sundstrom at [EMAIL PROTECTED] wrote: You should try this on some other OSes. and with Blackdowns VM http://www.blackdown.org if or when time permits ... /p ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
I am running blackdown and IBM marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Peter |Fagerlund |Sent: Monday, June 25, 2001 1:12 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] High load... | | |on 1-06-25 18.39, Dain Sundstrom at [EMAIL PROTECTED] wrote: | | You should try this on some other OSes. | |and with Blackdowns VM http://www.blackdown.org if or when time permits ... | |/p | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
marc fleury wrote: as I said the simpler design is with nopassivation stuff in it. I believe with gig ram machines floating around you can carefully design your deployment so that you will never need passivation. That's true for 99% of possible installations, but there will always be databases that won't fit into memory. Also, if you run a single VM on a 1GB linux box and try to give it that big a heap and have the number of users that that size implies, i suspect you'll have some mighty big threading and garbage collection issues with the current Tomcat/RMI implementations. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
marc fleury wrote: I am about to commit an MBean / EJB pair whose only purpose in life is to stress the cache locking logic. Because it is an MBean it never goes through the RMI layers and so we are seeing RAW performance of the logic that does the thread mutex semaphore and all taht... that was the part I had to optimize when I went to SUN... now with the new logic 50 threads all pinging on 1 object. on my new athlon it crawls to an halt at 50 clients in parallel (they wait 100ms before pinging again) and there is almost no invocation going through... This is a good test because it shows worst case, but can it be called a realistic test? I'm only bringing this up because, well, if I saw somebody with an application designed such that every user had to share a single synchronized object, I'd say well, yah, that'll perform fer shite! :( anybody ELSE seen this? I am almost leaning towards TOTALLY removing the passivating caches and associated mutex logic as is It does look like the behavior people have been complaining about. I'd not be in favor of permanently removing the passivating caches, however - making them non-default, sure, rewrite them absolutely, but they really have to be available for truly large installations. Truly large installations (running over N terabyte databases) will still need memory management. No that's not a typical installation, but don't you want to be able to support it? Ok I will say the word... this is shite ... or is it just me? marcf _ Marc Fleury, Ph.D [EMAIL PROTECTED] _ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Monday, June 25, 2001 12:50 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] High load... |You should try this on some other OSes. I believe that the sun vm on linux |uses a one-to-one mode (one java thread to one native thread). This model |has problems with thread contension becase all thread contension |is resolved |in the kernel which has to pass through the native layer. Other OSes have I will try that on windows 2000, I will commit the code soon, |I think the important question is Why do we have a passivation |cache? Why |did we add it and is the circumstances that led us to add it still |valid. I |often find optimiztions in my client's code for situations that simply are |not a problem any more. Optimizations make code more difficult to read and |therefore maintian. (By the way, we could make a arument along |the lines of |scaleability vs. performance of a single instance) | |I am all for making the code as simple a possible, as I said the simpler design is with nopassivation stuff in it. I believe with gig ram machines floating around you can carefully design your deployment so that you will never need passivation. I will try to keep it in but seriously need to revisit that code, I will take a couple of days of rabbit hole (paid time) to try and streamline it, it is key to the scalability and speed of execution On the other hand it seems to be pretty robust, I can't say I have BROKEN it ;-) A couple of points: - Does your test MBean chuck random rollbacks into the stress test as well? The original locking code seemed to be designed great if everything was working well, but seemed to have less thought put into when error conditions showed up(rollbacks). - Also, do you really have to have transactional locks for entities when you have commit option B and C? Wouldn't it be better to have an instance per transaction and only do method locks? - I plan on implementing a read-only instance interceptor for our app. We never want to lock for any reason with read-only entities. Maybe this would be useful in the code base. - Somebody had a great idea earlier of adding optimistic locking for CMP/JAWS. Along with this feature, you could write a specialized EntityInstanceInterceptor that did not do transactional locking with commit Option 'A'. This would be great for beans that had read-only invoked operations 90% of the time. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
hell, one thing at a time, my brain can work so fast |A couple of points: | |- Does your test MBean chuck random rollbacks into the stress test as well? |The original locking code seemed to be designed great if everything was |working well, but seemed to have less thought put into when error |conditions |showed up(rollbacks). yes it does, I randomly simulate exceptions,null pointers, and timeouts (by waiting) and see what happens in the cache. |- Also, do you really have to have transactional locks for entities when |you have commit option B and C? Wouldn't it be better to have an |instance per transaction and only do method locks? by design jboss2.0 does a transactional lock. |- I plan on implementing a read-only instance interceptor for our app. We |never want to lock for any reason with read-only entities. Maybe |this would |be useful in the code base. yes it would be very useful but put in 3.0... WE NEED TO FREEZE 2.4-2.6 AND MOVE DEVELOPMENT TO THE NEW BRANCH. (I thought it was frozen already?) anyway I will try to commit rabbit hole alpha this week (need to fix this poopoo first) and then we can go hog wash on the rewrite of the interceptors. It needs a serious overhaul. |- Somebody had a great idea earlier of adding optimistic locking for |CMP/JAWS. Along with this feature, you could write a specialized |EntityInstanceInterceptor that did not do transactional locking with |commit Option 'A'. This would be great for beans that had |read-only invoked |operations 90% of the time. yes, that would be interesting, BUT AGAIN I WANT TO FINISH OFF THE 2.X SERIES WITH THE BUGS REMOVED and the streamlined cache with transactional locking. I want 2.x to become a household name and for that I would want to fix what we have. It is not what you want today? I agree! code it and move it to 3.0. WE NEED STABILITY IN FEATURES So put all that good stuff in the new version. marcf | |Bill | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: |Will this affect commit Option A and B, which doesn't passivate? I'm not true. Even under option A if you are under heavy load, the cache can passivate under you. Good, I guessed from the code that passivation ment that we need to reload the data after activation (i.e., bean data should not be keept, in the vm, after a passivation). During passivation I de-referance the bean data. I'm just curious what was the passivation cache for? -dain Memory management. If your database contains 10 GB and you only have 1GB of memory, you'll need to swap out some bean based on some criteria (LRU by default) to make room. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
|This is a good test because it shows worst case, but can it be called a |realistic test? I'm only bringing this up because, well, if I saw |somebody with an application designed such that every user had to share |a single synchronized object, I'd say well, yah, that'll perform fer |shite! you don't get it, I don't want something realistic I want a COMPLETELY SYNTHETIC test banging on the cache so I can see where it leaks and breaks. You know how early planes were tested for air tightness? they are put under water with pressured cabins and they look for bubbles in the pool. Was that realistic ? hell no! was that useful? hell yes! | anybody ELSE seen this? I am almost leaning towards TOTALLY removing the | passivating caches and associated mutex logic as is | | |It does look like the behavior people have been complaining about. I'd |not be in favor of permanently removing the passivating caches, however well frankly part of the test is making sure that I see EXACTLY what doesn't work. We have a lot of noise but nothing concrete no repro case that I can work with. |- making them non-default, sure, rewrite them absolutely, but they |really have to be available for truly large installations. Truly large |installations (running over N terabyte databases) will still need memory |management. No that's not a typical installation, but don't you want to |be able to support it? yes... marcf | | | | Ok I will say the word... this is shite ... | | or is it just me? | | marcf | | _ | Marc Fleury, Ph.D | [EMAIL PROTECTED] | _ | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
I'm just curious what was the passivation cache for? Memory management. If your database contains 10 GB and you only have 1GB of memory, you'll need to swap out some bean based on some criteria (LRU by default) to make room. -danch Exactly, so what was the passivation cache? During passivation we want to dump data to make room for new objects. I think I'm lost... Why would we want to cache objects that we are tring to remove from memory? -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: I'm just curious what was the passivation cache for? Memory management. If your database contains 10 GB and you only have 1GB of memory, you'll need to swap out some bean based on some criteria (LRU by default) to make room. -danch Exactly, so what was the passivation cache? During passivation we want to dump data to make room for new objects. I think I'm lost... Why would we want to cache objects that we are tring to remove from memory? -dain It's a cache that passivates when it has over a certain number of object within it. It doesn't passivate what it's trying to cache, it passivates the overage. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] High load...
I'm just curious what was the passivation cache for? Memory management. If your database contains 10 GB and you only have 1GB of memory, you'll need to swap out some bean based on some criteria (LRU by default) to make room. -danch Exactly, so what was the passivation cache? During passivation we want to dump data to make room for new objects. I think I'm lost... Why would we want to cache objects that we are tiring to remove from memory? -dain It's a cache that passivates when it has over a certain number of object within it. It doesn't passivate what it's trying to cache, it passivates the overage. So if we remove the passivation cache, do we loose commit Option A? If not, how do we keep bean data alive while passivated? I still may not understand this. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: So if we remove the passivation cache, do we loose commit Option A? If not, how do we keep bean data alive while passivated? I still may not understand this. I think Mark is just suggesting losing the passivation part of the cache. The cache we keep, it just keeps growing and growing and growing. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
So if we remove the passivation cache, do we loose commit Option A? If not, how do we keep bean data alive while passivated? I still may not understand this. I think Mark is just suggesting losing the passivation part of the cache. The cache we keep, it just keeps growing and growing and growing. -danch I find that hard to believe. Would we reboot the server to cear the cache? I thought he was suggesting removing the cache and just passivating the beans. I don't want to put words into marc's mouth so hopefully he will expand on his suggestion. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
