RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()
Jason, I'm going to combine multiple email replies into one. Please switch back to QueuedPessimisticEJBLock. We're trying to make this the default for JBoss since it scales better. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Monday, August 20, 2001 7:06 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore() I am using commit option B, since it might be possible that another process is using the database... though I am 100% sure that I have sole access to the database I am using. You probably already know this but ejbLoad will get called whenever the entity becomes part of the transaction If I run the first producer with the first MDB offline, then connect the MDB everything seems to be fine. I have run a few tests through in this manner and I have not had problem yet, where as if I try to have the both up together it will work only once after all nodes have been started (usually) and will fail most times after that. I should be able to have more than one thread update a single entity at the same time (or rather ordered as the container dictates) right? By more than one thread you mean more than one transaction? Yes, you can have more than one transaction, but remember, this is pessimistic locking. The entity will be locked until the transaction commits. All other accesses to the entity will be blocked until the entity is committed by the first transaction. so you see: 1. setModified() 2. ejbLoad So there is no ejbStore() in between setModified() and ejbLoad()? Correct. I also very rarly a javax.ejb.DuplicateKeyException, which happend to just pop up as I was running these tests. I assume you're using commit option 'A'? Nope, option 'B'. isModified only get's called before a storeEntity(ejbStore()) It does not get called before an ejbLoad(). storeEntity will get called on a transaction commit. Also when a finder or remove method is called, but only beans within the transaction will get stored in this case. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Monday, August 20, 2001 7:34 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore() On Mon, 20 Aug 2001, Bill Burke wrote: A thing to note. Whenever a finder or remove is called within a transaction, every entity of every type that is part of the transaction is synchronized with the database. Could this be your problem? The (5) MDB uses findByPrimaryKey to locate all of the beans (a, b, c d). So, if there is an entity and modified by one thread under one tx, and another thread/tx does a findby, the first thread will loose its data due to a ejbLoad from the second? Not at all. Remember. Pessimistic locking! Once an entity becomes part of a tx, all other threads/transactions are blocked until the tx commits. This is essentially what I am seeing, though I can not really tell that this I just found a bug in QueuedPessimisticEJBLock that may be causing this problem. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()
I'm going to combine multiple email replies into one. Please switch back to QueuedPessimisticEJBLock. We're trying to make this the default for JBoss since it scales better. Ok. I was not sure if one was more stable than the other. I am using commit option B, since it might be possible that another process is using the database... though I am 100% sure that I have sole access to the database I am using. You probably already know this but ejbLoad will get called whenever the entity becomes part of the transaction I figured that much, but I was not really sure. If I run the first producer with the first MDB offline, then connect the MDB everything seems to be fine. I have run a few tests through in this manner and I have not had problem yet, where as if I try to have the both up together it will work only once after all nodes have been started (usually) and will fail most times after that. I should be able to have more than one thread update a single entity at the same time (or rather ordered as the container dictates) right? By more than one thread you mean more than one transaction? Yes, you can have more than one transaction, but remember, this is pessimistic locking. The entity will be locked until the transaction commits. All other accesses to the entity will be blocked until the entity is committed by the first transaction. That is not the behavior that I was seeing, perhaps your change to Queued* fixed that. Not sure at the moment. I think I did find one rather large application error, where the last MDB updated an entity, and then tried to remove it (and all other related entities) at the end, all inside of one tx. I made a dumb ass mistake and changed the method which removed these to be NotSupported, which was causing a TX timeout waiting for the calling TX to complete before anything could be removed... Since the last update never commits, the database always looks inconsistent. Any ways, I think that this was the problem that I was seeing with the Simple* lock. Not at all. Remember. Pessimistic locking! Once an entity becomes part of a tx, all other threads/transactions are blocked until the tx commits. This is essentially what I am seeing, though I can not really tell that this I just found a bug in QueuedPessimisticEJBLock that may be causing this problem. Cool. I will let you know if this fixes the problem I am seeing. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Tuesday, August 21, 2001 4:36 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore() I'm going to combine multiple email replies into one. Please switch back to QueuedPessimisticEJBLock. We're trying to make this the default for JBoss since it scales better. Ok. I was not sure if one was more stable than the other. I am using commit option B, since it might be possible that another process is using the database... though I am 100% sure that I have sole access to the database I am using. You probably already know this but ejbLoad will get called whenever the entity becomes part of the transaction I figured that much, but I was not really sure. If I run the first producer with the first MDB offline, then connect the MDB everything seems to be fine. I have run a few tests through in this manner and I have not had problem yet, where as if I try to have the both up together it will work only once after all nodes have been started (usually) and will fail most times after that. I should be able to have more than one thread update a single entity at the same time (or rather ordered as the container dictates) right? By more than one thread you mean more than one transaction? Yes, you can have more than one transaction, but remember, this is pessimistic locking. The entity will be locked until the transaction commits. All other accesses to the entity will be blocked until the entity is committed by the first transaction. That is not the behavior that I was seeing, perhaps your change to Queued* fixed that. Not sure at the moment. I think I did find one rather large The Queued* bug fix should show the behaviour I talked about above. Let me know. Thanks, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()
I have not seen this problem again... so far. I am running larger tests to confirm. --jason On Tue, 21 Aug 2001, Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Tuesday, August 21, 2001 4:36 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore() I'm going to combine multiple email replies into one. Please switch back to QueuedPessimisticEJBLock. We're trying to make this the default for JBoss since it scales better. Ok. I was not sure if one was more stable than the other. I am using commit option B, since it might be possible that another process is using the database... though I am 100% sure that I have sole access to the database I am using. You probably already know this but ejbLoad will get called whenever the entity becomes part of the transaction I figured that much, but I was not really sure. If I run the first producer with the first MDB offline, then connect the MDB everything seems to be fine. I have run a few tests through in this manner and I have not had problem yet, where as if I try to have the both up together it will work only once after all nodes have been started (usually) and will fail most times after that. I should be able to have more than one thread update a single entity at the same time (or rather ordered as the container dictates) right? By more than one thread you mean more than one transaction? Yes, you can have more than one transaction, but remember, this is pessimistic locking. The entity will be locked until the transaction commits. All other accesses to the entity will be blocked until the entity is committed by the first transaction. That is not the behavior that I was seeing, perhaps your change to Queued* fixed that. Not sure at the moment. I think I did find one rather large The Queued* bug fix should show the behaviour I talked about above. Let me know. Thanks, 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] ejbLoad() on a modified bean w/o ejbStore()
I have pushed close to 600x3 transactions through our system and have not run into any problems yet. Once I get to 1000x3 I will know for sure. Looks really good so far! --jason On Tue, 21 Aug 2001, Jason Dillon wrote: I have not seen this problem again... so far. I am running larger tests to confirm. --jason On Tue, 21 Aug 2001, Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Tuesday, August 21, 2001 4:36 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore() I'm going to combine multiple email replies into one. Please switch back to QueuedPessimisticEJBLock. We're trying to make this the default for JBoss since it scales better. Ok. I was not sure if one was more stable than the other. I am using commit option B, since it might be possible that another process is using the database... though I am 100% sure that I have sole access to the database I am using. You probably already know this but ejbLoad will get called whenever the entity becomes part of the transaction I figured that much, but I was not really sure. If I run the first producer with the first MDB offline, then connect the MDB everything seems to be fine. I have run a few tests through in this manner and I have not had problem yet, where as if I try to have the both up together it will work only once after all nodes have been started (usually) and will fail most times after that. I should be able to have more than one thread update a single entity at the same time (or rather ordered as the container dictates) right? By more than one thread you mean more than one transaction? Yes, you can have more than one transaction, but remember, this is pessimistic locking. The entity will be locked until the transaction commits. All other accesses to the entity will be blocked until the entity is committed by the first transaction. That is not the behavior that I was seeing, perhaps your change to Queued* fixed that. Not sure at the moment. I think I did find one rather large The Queued* bug fix should show the behaviour I talked about above. Let me know. Thanks, 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 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()
I just checked an the same behavior exists with the SimplePessimisticEJBLock. =( --jason On Mon, 20 Aug 2001, Jason Dillon wrote: I am running into another odd problem, this time it looks like ejbLoad() is being called on a modified entity with out ejbStore() being called first. I am not really sure why this would happen, nor do I know where to start looking. I am using isModified() to show that an entity has changed. The current impl simply logs a message and returns a boolean flag. I implemented a setModified(), which sets that flag to true and logs a message. I am seeing bean is modified message, then shortly after on the same entity I see an ejbLoad() but there is no message about checking if the entity has been modified. This might be caused by two different threads accessing the bean, so the tx might be confused... but it is my understanding that this should work. Essentially one user thread invokes a SFSB in a loop. This bean creates jms messages. A MDB on another machine does something with the message and sends a response message back. Then another MDB in the same VM as the SFSB takes the message and updates 3 entities that were created by the SFSB to track the message. Due to this problem, the bookkeeping for the messages are inconsistent, which more or less breaks the application completely. Is it possible that this might be caused by the new locking system? I am currently use the QueuedPessimisticEJBLock locking policy on all entities. I might try SimplePessimisticEJBLock, but I wanted to get some input from the experts first, as to why this might be happening. At first I thought that there might be more than one Entity per PK being created, but I am not seeing that. If someone could advise me on where I can look to find out more how this works it would really be appreciated. --jason ___ 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] ejbLoad() on a modified bean w/o ejbStore()
Jason, Are you using jaws or cmp? -dain - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 20, 2001 5:38 PM Subject: Re: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore() I just checked an the same behavior exists with the SimplePessimisticEJBLock. =( --jason On Mon, 20 Aug 2001, Jason Dillon wrote: I am running into another odd problem, this time it looks like ejbLoad() is being called on a modified entity with out ejbStore() being called first. I am not really sure why this would happen, nor do I know where to start looking. I am using isModified() to show that an entity has changed. The current impl simply logs a message and returns a boolean flag. I implemented a setModified(), which sets that flag to true and logs a message. I am seeing bean is modified message, then shortly after on the same entity I see an ejbLoad() but there is no message about checking if the entity has been modified. This might be caused by two different threads accessing the bean, so the tx might be confused... but it is my understanding that this should work. Essentially one user thread invokes a SFSB in a loop. This bean creates jms messages. A MDB on another machine does something with the message and sends a response message back. Then another MDB in the same VM as the SFSB takes the message and updates 3 entities that were created by the SFSB to track the message. Due to this problem, the bookkeeping for the messages are inconsistent, which more or less breaks the application completely. Is it possible that this might be caused by the new locking system? I am currently use the QueuedPessimisticEJBLock locking policy on all entities. I might try SimplePessimisticEJBLock, but I wanted to get some input from the experts first, as to why this might be happening. At first I thought that there might be more than one Entity per PK being created, but I am not seeing that. If someone could advise me on where I can look to find out more how this works it would really be appreciated. --jason ___ 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] ejbLoad() on a modified bean w/o ejbStore()
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Monday, August 20, 2001 6:15 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore() I am running into another odd problem, this time it looks like ejbLoad() is being called on a modified entity with out ejbStore() being called first. I am not really sure why this would happen, nor do I know where to start looking. I am using isModified() to show that an entity has changed. The current impl simply logs a message and returns a boolean flag. I implemented a setModified(), which sets that flag to true and logs a message. I am seeing bean is modified message, then shortly after on the same entity I see an ejbLoad() but there is no message about checking if the entity has been modified. so you see: 1. setModified() 2. ejbLoad So there is no ejbStore() in between setModified() and ejbLoad()? I assume you're using commit option 'A'? This might be caused by two different threads accessing the bean, so the tx might be confused... but it is my understanding that this should work. 2 different threads with the same TX? Can you be more specific on the transaction boundaries and Threads? What threads of execution do transactions begin and end? Are the entities created in separate transactions or in the same transaction? Can you draw some kind of flow here? Can you output the exact order of messages and where the problem is? Essentially one user thread invokes a SFSB in a loop. This bean creates jms messages. A MDB on another machine does something with the message and sends a response message back. Then another MDB in the same VM as the SFSB takes the message and updates 3 entities that were created by the SFSB to track the message. Due to this problem, the bookkeeping for the messages are inconsistent, which more or less breaks the application completely. I'm really confused here. You're going to have to be more specific. Sorry. Is it possible that this might be caused by the new locking system? I am currently use the QueuedPessimisticEJBLock locking policy on all entities. I might try SimplePessimisticEJBLock, but I wanted to get some input from the experts first, as to why this might be happening. At first I thought that there might be more than one Entity per PK being created, but I am not seeing that. If someone could advise me on where I can look to find out more how this works it would really be appreciated. --jason ___ 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] ejbLoad() on a modified bean w/o ejbStore()
A thing to note. Whenever a finder or remove is called within a transaction, every entity of every type that is part of the transaction is synchronized with the database. Could this be your problem? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Monday, August 20, 2001 6:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore() I just checked an the same behavior exists with the SimplePessimisticEJBLock. =( --jason On Mon, 20 Aug 2001, Jason Dillon wrote: I am running into another odd problem, this time it looks like ejbLoad() is being called on a modified entity with out ejbStore() being called first. I am not really sure why this would happen, nor do I know where to start looking. I am using isModified() to show that an entity has changed. The current impl simply logs a message and returns a boolean flag. I implemented a setModified(), which sets that flag to true and logs a message. I am seeing bean is modified message, then shortly after on the same entity I see an ejbLoad() but there is no message about checking if the entity has been modified. This might be caused by two different threads accessing the bean, so the tx might be confused... but it is my understanding that this should work. Essentially one user thread invokes a SFSB in a loop. This bean creates jms messages. A MDB on another machine does something with the message and sends a response message back. Then another MDB in the same VM as the SFSB takes the message and updates 3 entities that were created by the SFSB to track the message. Due to this problem, the bookkeeping for the messages are inconsistent, which more or less breaks the application completely. Is it possible that this might be caused by the new locking system? I am currently use the QueuedPessimisticEJBLock locking policy on all entities. I might try SimplePessimisticEJBLock, but I wanted to get some input from the experts first, as to why this might be happening. At first I thought that there might be more than one Entity per PK being created, but I am not seeing that. If someone could advise me on where I can look to find out more how this works it would really be appreciated. --jason ___ 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] ejbLoad() on a modified bean w/o ejbStore()
I am using commit option B, since it might be possible that another process is using the database... though I am 100% sure that I have sole access to the database I am using. If I run the first producer with the first MDB offline, then connect the MDB everything seems to be fine. I have run a few tests through in this manner and I have not had problem yet, where as if I try to have the both up together it will work only once after all nodes have been started (usually) and will fail most times after that. I should be able to have more than one thread update a single entity at the same time (or rather ordered as the container dictates) right? --jason On Mon, 20 Aug 2001, Jason Dillon wrote: I just checked an the same behavior exists with the SimplePessimisticEJBLock. =( --jason On Mon, 20 Aug 2001, Jason Dillon wrote: I am running into another odd problem, this time it looks like ejbLoad() is being called on a modified entity with out ejbStore() being called first. I am not really sure why this would happen, nor do I know where to start looking. I am using isModified() to show that an entity has changed. The current impl simply logs a message and returns a boolean flag. I implemented a setModified(), which sets that flag to true and logs a message. I am seeing bean is modified message, then shortly after on the same entity I see an ejbLoad() but there is no message about checking if the entity has been modified. This might be caused by two different threads accessing the bean, so the tx might be confused... but it is my understanding that this should work. Essentially one user thread invokes a SFSB in a loop. This bean creates jms messages. A MDB on another machine does something with the message and sends a response message back. Then another MDB in the same VM as the SFSB takes the message and updates 3 entities that were created by the SFSB to track the message. Due to this problem, the bookkeeping for the messages are inconsistent, which more or less breaks the application completely. Is it possible that this might be caused by the new locking system? I am currently use the QueuedPessimisticEJBLock locking policy on all entities. I might try SimplePessimisticEJBLock, but I wanted to get some input from the experts first, as to why this might be happening. At first I thought that there might be more than one Entity per PK being created, but I am not seeing that. If someone could advise me on where I can look to find out more how this works it would really be appreciated. --jason ___ 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] ejbLoad() on a modified bean w/o ejbStore()
EJB 1.1 cmp... that is jaws right? --jason On Mon, 20 Aug 2001, Dain Sundstrom wrote: Jason, Are you using jaws or cmp? -dain - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 20, 2001 5:38 PM Subject: Re: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore() I just checked an the same behavior exists with the SimplePessimisticEJBLock. =( --jason On Mon, 20 Aug 2001, Jason Dillon wrote: I am running into another odd problem, this time it looks like ejbLoad() is being called on a modified entity with out ejbStore() being called first. I am not really sure why this would happen, nor do I know where to start looking. I am using isModified() to show that an entity has changed. The current impl simply logs a message and returns a boolean flag. I implemented a setModified(), which sets that flag to true and logs a message. I am seeing bean is modified message, then shortly after on the same entity I see an ejbLoad() but there is no message about checking if the entity has been modified. This might be caused by two different threads accessing the bean, so the tx might be confused... but it is my understanding that this should work. Essentially one user thread invokes a SFSB in a loop. This bean creates jms messages. A MDB on another machine does something with the message and sends a response message back. Then another MDB in the same VM as the SFSB takes the message and updates 3 entities that were created by the SFSB to track the message. Due to this problem, the bookkeeping for the messages are inconsistent, which more or less breaks the application completely. Is it possible that this might be caused by the new locking system? I am currently use the QueuedPessimisticEJBLock locking policy on all entities. I might try SimplePessimisticEJBLock, but I wanted to get some input from the experts first, as to why this might be happening. At first I thought that there might be more than one Entity per PK being created, but I am not seeing that. If someone could advise me on where I can look to find out more how this works it would really be appreciated. --jason ___ 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] ejbLoad() on a modified bean w/o ejbStore()
so you see: 1. setModified() 2. ejbLoad So there is no ejbStore() in between setModified() and ejbLoad()? Correct. I also very rarly a javax.ejb.DuplicateKeyException, which happend to just pop up as I was running these tests. I assume you're using commit option 'A'? Nope, option 'B'. This might be caused by two different threads accessing the bean, so the tx might be confused... but it is my understanding that this should work. 2 different threads with the same TX? There is one user thread (one that I new Thread()'d) and then there are the MDB threads. The user thread calls a bean method with RequiresNew and all of the MDB's are Required, so I would assume that each thread has its own tx context. They do happend to update one single entity, along with a slew of entities related to this one. Can you be more specific on the transaction boundaries and Threads? What threads of execution do transactions begin and end? Are the entities created in separate transactions or in the same transaction? Can you draw some kind of flow here? Yikes... I can try. 1) client - SLSB Creates two entities (a, b), sends one message to a remote JMS queue, returns. 2) MDB - JMX Creates a user-thread and a new SFSB to process the request and starts it. 3) user-thread - SFSB (RequiresNew) Creates two entities (x, y), updates entity b, sends one message to a remote JMS queue. If this is the last request, then update entities a b, else loop (back to 3) 4) MDB - JMX Performs some work (outside of a TX), then sends a response message to a JMS queue. 5) MDB Updates entities x y for the corresponding request id. Updates entity b. If this is the last response, then update a b. Does that help any? I am not really sure what the best diagrm would be to explain what is going on, short of a full blown uml sequence diagram. Like I said before, each MDB is set to Required. The (4) MDB tx is only really used to make sure that the JMX call completed successfully, then it stops, since this could take longer than the TX time out to complete. Can you output the exact order of messages and where the problem is? Do you mean log messages or JMS messages? Essentially one user thread invokes a SFSB in a loop. This bean creates jms messages. A MDB on another machine does something with the message and sends a response message back. Then another MDB in the same VM as the SFSB takes the message and updates 3 entities that were created by the SFSB to track the message. I'm really confused here. You're going to have to be more specific. Sorry. Sorry, I do not mean to confuse you. Hopefully the above will have cleared that up for you. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()
I am also seening some odd behavior where the final tx never gets commited. I see the tx being suspended, then resumed, an application method log which calls setModified(), then some more supend/resumes and then a few more application methods. Then I get to an app method which will call a bunch of removes() which runs under NotSupported. At this point the application hangs and I will eventually get a tx timeout from the SimplePessimisticEJBLock.doSchedule(). This behavior seems to be a bit irratic, as I could probably restart all of the components and run it again just fine. But once it gets into a state of funk, it is more or less non-functional from that point out. --jason On Mon, 20 Aug 2001, Bill Burke wrote: A thing to note. Whenever a finder or remove is called within a transaction, every entity of every type that is part of the transaction is synchronized with the database. Could this be your problem? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Monday, August 20, 2001 6:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore() I just checked an the same behavior exists with the SimplePessimisticEJBLock. =( --jason On Mon, 20 Aug 2001, Jason Dillon wrote: I am running into another odd problem, this time it looks like ejbLoad() is being called on a modified entity with out ejbStore() being called first. I am not really sure why this would happen, nor do I know where to start looking. I am using isModified() to show that an entity has changed. The current impl simply logs a message and returns a boolean flag. I implemented a setModified(), which sets that flag to true and logs a message. I am seeing bean is modified message, then shortly after on the same entity I see an ejbLoad() but there is no message about checking if the entity has been modified. This might be caused by two different threads accessing the bean, so the tx might be confused... but it is my understanding that this should work. Essentially one user thread invokes a SFSB in a loop. This bean creates jms messages. A MDB on another machine does something with the message and sends a response message back. Then another MDB in the same VM as the SFSB takes the message and updates 3 entities that were created by the SFSB to track the message. Due to this problem, the bookkeeping for the messages are inconsistent, which more or less breaks the application completely. Is it possible that this might be caused by the new locking system? I am currently use the QueuedPessimisticEJBLock locking policy on all entities. I might try SimplePessimisticEJBLock, but I wanted to get some input from the experts first, as to why this might be happening. At first I thought that there might be more than one Entity per PK being created, but I am not seeing that. If someone could advise me on where I can look to find out more how this works it would really be appreciated. --jason ___ 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] ejbLoad() on a modified bean w/o ejbStore()
Hrm... I think this is just me being confused about FormatId and GlobalId... --jason On Mon, 20 Aug 2001, Jason Dillon wrote: Here is another bit of oddness, which I do not quite understand. I was trolling through the logs of a run which has odd tx behavior and saw this at the end: snip 2001-08-20 18:20:18,894 com.boldfish.does.mailing.persistence.internal.MailingPOEJB@2q8an [Thread Pool Worker-11] DEBUG - changing state from 1 to 2 2001-08-20 18:20:18,894 com.boldfish.does.mailing.persistence.internal.MailingPOEJB@2q8an [Thread Pool Worker-11] INFO - bean marked as modified 2001-08-20 18:20:18,894 org.jboss.tm.TxManager [Thread Pool Worker-11] DEBUG - suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=eng-ecr3a//62, BranchQual=] 2001-08-20 18:20:18,894 org.jboss.tm.TxManager [Thread Pool Worker-11] DEBUG - resumed tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=eng-ecr3a//62, BranchQual=] 2001-08-20 18:20:18,895 org.jboss.ejb.plugins.LogInterceptor [Thread Pool Worker-11] DEBUG - Invoke: [13] cleanup(com.boldfish.does.job.persistence.JobHome:13) 2001-08-20 18:20:18,895 org.jboss.tm.TxManager [Thread Pool Worker-11] DEBUG - suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=eng-ecr3a//62, BranchQual=] 2001-08-20 18:20:18,895 com.boldfish.does.mailing.persistence.internal.MailingPOEJB@2q8an [Thread Pool Worker-11] DEBUG - [ cleaning up MRI objects for job, com.boldfish.does.job.persistence.JobHome:13 ] 2001-08-20 18:20:19,060 org.jboss.ejb.plugins.LogInterceptor [Thread Pool Worker-11] DEBUG - Invoke: [13] getDetails() 2001-08-20 18:20:19,061 org.jboss.tm.TxCapsule [Thread Pool Worker-11] DEBUG - Reused instance for tx=XidImpl [FormatId=257, GlobalId=eng-ecr3a//63, BranchQual=] 2001-08-20 18:20:19,061 org.jboss.tm.TxManager [Thread Pool Worker-11] DEBUG - began tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=eng-ecr3a//63, BranchQual=] /snip I left in some of the application logs to show that some bean has been modified. The bit at the end is what is confusing me. It is resuing the tx... but the tx it is reusing has not committed yet. Perhaps I am reading this wrong, but... perhaps not. This is the tx that occurs near the end of a run which completed successfully (acording to the logs, but the last tx never commited and thus the database is out of sync). --jason On Mon, 20 Aug 2001, Bill Burke wrote: A thing to note. Whenever a finder or remove is called within a transaction, every entity of every type that is part of the transaction is synchronized with the database. Could this be your problem? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Monday, August 20, 2001 6:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore() I just checked an the same behavior exists with the SimplePessimisticEJBLock. =( --jason On Mon, 20 Aug 2001, Jason Dillon wrote: I am running into another odd problem, this time it looks like ejbLoad() is being called on a modified entity with out ejbStore() being called first. I am not really sure why this would happen, nor do I know where to start looking. I am using isModified() to show that an entity has changed. The current impl simply logs a message and returns a boolean flag. I implemented a setModified(), which sets that flag to true and logs a message. I am seeing bean is modified message, then shortly after on the same entity I see an ejbLoad() but there is no message about checking if the entity has been modified. This might be caused by two different threads accessing the bean, so the tx might be confused... but it is my understanding that this should work. Essentially one user thread invokes a SFSB in a loop. This bean creates jms messages. A MDB on another machine does something with the message and sends a response message back. Then another MDB in the same VM as the SFSB takes the message and updates 3 entities that were created by the SFSB to track the message. Due to this problem, the bookkeeping for the messages are inconsistent, which more or less breaks the application completely. Is it possible that this might be caused by the new locking system? I am currently use the QueuedPessimisticEJBLock locking policy on all entities. I might try SimplePessimisticEJBLock, but I wanted to get some input from the experts first, as to why this might be happening. At first I thought that there might be more than one Entity per PK being created, but I am not seeing that. If someone could advise me on where I can look to find out more how this works it would really be appreciated. --jason
