Re: [JBoss-user] ejbStore and finder method
From: "danch" [EMAIL PROTECTED] Emmanuel Sciara wrote: I would tend to agree with that. IMHO no commit means that you can rollback. It does not mean that you don't perform any actions what so ever. I guess the server could take one of two approaches (or both and leave the option to the developer): - use the rollback capabilities of the underlying datastore. This means performing updates and creates straight away to the database, which performance-wise is not great. - maintain the state at the server level with some kind of caching. This means performing updates and creates to the datastore only if there is no rollback required and commit straight after. That would probably provide better performance, but the caching layer seems to have to be fairly complexe to me. The EJB spec dictates the behavior. If you look in section 9.5 of the 1.1 spec, it indicates that when an entity is created, its initial state should be pushed into the database right away, but that update operations should be done as part of the commit process. So we seem to have a slight compliance issue here. Mark, what is the best way to raise the problem (if you agree there is a problem). Send it to the developer list? Should I raise a bug in Bugzilla? Sing a song? (huh?! Maybe not, I am an appalling singer) :) In both cases, I think you should be able to find an entity you have created in the same transaction. That does follow the "Law of least astonishment" Huh? Emmanuel Do I make sens here or is there something I have not considered? Emmanuel - Original Message - From: "Dan Christopherson" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 04, 2001 4:31 PM Subject: RE: [JBoss-user] ejbStore and finder method I'm not so sure it's that simple, Marc. WRT to CMP created bean especially, the 1.1 spec indicates that the bean's state should be pushed into the database as part of the 'create' call. Shouldn't custom finders then find it? Assuming that the database allows a transaction to see what it has already done, that is. As for the problem where the customer finders come in, shouldn't the container do a cache look-aside sort of a thing? Oof, it then has to make sure transactions match, doesn't it. But the (InstanceInterceptor? TxInterceptor? one or the other) will block if the transactions don't match. A agree, obviously, that no commit means no commit, but I think it's reasonable to expect a transaction to see its own work. Implementing this look aside would require a bit of an egg-shell walk, perhaps. On Wed, 4 Apr 2001, marc fleury wrote: |Or is it simply not part of the spec? by definition, no commit - no commit marc ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user -- Dan Christopherson (danch) nVisia Technical Architect (www.nvisia.com) Opinions expressed are mine and do not neccessarily reflect any position or opinion of nVISIA. -- - If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait. -Eben Moglen ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] ejbStore and finder method
I would tend to agree with that. IMHO no commit means that you can rollback. It does not mean that you don't perform any actions what so ever. I guess the server could take one of two approaches (or both and leave the option to the developer): - use the rollback capabilities of the underlying datastore. This means performing updates and creates straight away to the database, which performance-wise is not great. - maintain the state at the server level with some kind of caching. This means performing updates and creates to the datastore only if there is no rollback required and commit straight after. That would probably provide better performance, but the caching layer seems to have to be fairly complexe to me. In both cases, I think you should be able to find an entity you have created in the same transaction. Do I make sens here or is there something I have not considered? Emmanuel - Original Message - From: "Dan Christopherson" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 04, 2001 4:31 PM Subject: RE: [JBoss-user] ejbStore and finder method I'm not so sure it's that simple, Marc. WRT to CMP created bean especially, the 1.1 spec indicates that the bean's state should be pushed into the database as part of the 'create' call. Shouldn't custom finders then find it? Assuming that the database allows a transaction to see what it has already done, that is. As for the problem where the customer finders come in, shouldn't the container do a cache look-aside sort of a thing? Oof, it then has to make sure transactions match, doesn't it. But the (InstanceInterceptor? TxInterceptor? one or the other) will block if the transactions don't match. A agree, obviously, that no commit means no commit, but I think it's reasonable to expect a transaction to see its own work. Implementing this look aside would require a bit of an egg-shell walk, perhaps. On Wed, 4 Apr 2001, marc fleury wrote: |Or is it simply not part of the spec? by definition, no commit - no commit marc ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user -- Dan Christopherson (danch) nVisia Technical Architect (www.nvisia.com) Opinions expressed are mine and do not neccessarily reflect any position or opinion of nVISIA. -- - If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait. -Eben Moglen ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] ejbStore and finder method
|Or is it simply not part of the spec? by definition, no commit - no commit marc ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] ejbStore and finder method
If the database isolation level is set to read-uncommitted, then the finder should be able to read the row that was inserted in the create(). jim - Original Message - From: "Dan Christopherson" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 04, 2001 11:31 AM Subject: RE: [JBoss-user] ejbStore and finder method I'm not so sure it's that simple, Marc. WRT to CMP created bean especially, the 1.1 spec indicates that the bean's state should be pushed into the database as part of the 'create' call. Shouldn't custom finders then find it? Assuming that the database allows a transaction to see what it has already done, that is. As for the problem where the customer finders come in, shouldn't the container do a cache look-aside sort of a thing? Oof, it then has to make sure transactions match, doesn't it. But the (InstanceInterceptor? TxInterceptor? one or the other) will block if the transactions don't match. A agree, obviously, that no commit means no commit, but I think it's reasonable to expect a transaction to see its own work. Implementing this look aside would require a bit of an egg-shell walk, perhaps. On Wed, 4 Apr 2001, marc fleury wrote: |Or is it simply not part of the spec? by definition, no commit - no commit marc ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user -- Dan Christopherson (danch) nVisia Technical Architect (www.nvisia.com) Opinions expressed are mine and do not neccessarily reflect any position or opinion of nVISIA. --- If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait. -Eben Moglen ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] ejbStore and finder method
On Wed, 4 Apr 2001, James Cook wrote: If the database isolation level is set to read-uncommitted, then the finder should be able to read the row that was inserted in the create(). That's even from a different transaction, though, isn't it? I believe (I'm not the person with the original problem) that the issue was being able to re-find an entity from the same transaction that created it. jim - Original Message - From: "Dan Christopherson" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 04, 2001 11:31 AM Subject: RE: [JBoss-user] ejbStore and finder method I'm not so sure it's that simple, Marc. WRT to CMP created bean especially, the 1.1 spec indicates that the bean's state should be pushed into the database as part of the 'create' call. Shouldn't custom finders then find it? Assuming that the database allows a transaction to see what it has already done, that is. As for the problem where the customer finders come in, shouldn't the container do a cache look-aside sort of a thing? Oof, it then has to make sure transactions match, doesn't it. But the (InstanceInterceptor? TxInterceptor? one or the other) will block if the transactions don't match. A agree, obviously, that no commit means no commit, but I think it's reasonable to expect a transaction to see its own work. Implementing this look aside would require a bit of an egg-shell walk, perhaps. On Wed, 4 Apr 2001, marc fleury wrote: |Or is it simply not part of the spec? by definition, no commit - no commit marc ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user -- Dan Christopherson (danch) nVisia Technical Architect (www.nvisia.com) Opinions expressed are mine and do not neccessarily reflect any position or opinion of nVISIA. --- If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait. -Eben Moglen ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user -- Dan Christopherson (danch) nVisia Technical Architect (www.nvisia.com) Opinions expressed are mine and do not neccessarily reflect any position or opinion of nVISIA. --- If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait. -Eben Moglen ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] ejbStore and finder method
- Original Message - From: "Dan Christopherson" [EMAIL PROTECTED] If the database isolation level is set to read-uncommitted, then the finder should be able to read the row that was inserted in the create(). That's even from a different transaction, though, isn't it? I believe (I'm not the person with the original problem) that the issue was being able to re-find an entity from the same transaction that created it. Even the same transaction should be able to see (read) the results of the insert statement. jim jim - Original Message - From: "Dan Christopherson" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 04, 2001 11:31 AM Subject: RE: [JBoss-user] ejbStore and finder method I'm not so sure it's that simple, Marc. WRT to CMP created bean especially, the 1.1 spec indicates that the bean's state should be pushed into the database as part of the 'create' call. Shouldn't custom finders then find it? Assuming that the database allows a transaction to see what it has already done, that is. As for the problem where the customer finders come in, shouldn't the container do a cache look-aside sort of a thing? Oof, it then has to make sure transactions match, doesn't it. But the (InstanceInterceptor? TxInterceptor? one or the other) will block if the transactions don't match. A agree, obviously, that no commit means no commit, but I think it's reasonable to expect a transaction to see its own work. Implementing this look aside would require a bit of an egg-shell walk, perhaps. On Wed, 4 Apr 2001, marc fleury wrote: |Or is it simply not part of the spec? by definition, no commit - no commit marc ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user -- Dan Christopherson (danch) nVisia Technical Architect (www.nvisia.com) Opinions expressed are mine and do not neccessarily reflect any position or opinion of nVISIA. --- If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait. -Eben Moglen ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user -- Dan Christopherson (danch) nVisia Technical Architect (www.nvisia.com) Opinions expressed are mine and do not neccessarily reflect any position or opinion of nVISIA. --- If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait. -Eben Moglen ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] ejbStore and finder method
Oh. Right. I guess that we wouldn't, although I never read that. I am under the same assumption that you are. The current transaction usually creates a snapshot of the database and does its work there. So I assume that queries in the same transaction should see the results no matter what the isolation level. jim - Original Message - From: "Dan Christopherson" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 04, 2001 3:26 PM Subject: Re: [JBoss-user] ejbStore and finder method On Wed, 4 Apr 2001, James Cook wrote: - Original Message - From: "Dan Christopherson" [EMAIL PROTECTED] If the database isolation level is set to read-uncommitted, then the finder should be able to read the row that was inserted in the create(). That's even from a different transaction, though, isn't it? I believe (I'm not the person with the original problem) that the issue was being able to re-find an entity from the same transaction that created it. Even the same transaction should be able to see (read) the results of the insert statement. Yes, but what I'm getting at is that we don't need read-uncommitted for that, do we? -- Dan Christopherson (danch) nVisia Technical Architect (www.nvisia.com) Opinions expressed are mine and do not neccessarily reflect any position or opinion of nVISIA. --- If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait. -Eben Moglen ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] ejbStore and finder method
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Todd Huss |Sent: Wednesday, March 28, 2001 5:42 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-user] ejbStore and finder method | | |I have a BMP entity bean which I update and then stop using. I then use a |custom finder method on its respective home interface which should (with |the update I just made) find it and a couple other entity beans. When I |run the finder method though, the bean I just updated doesn't show up, |only the other beans, even though it too matches the selection |criteria. | |The problem seems to be, that because this all happens in one transaction |(container managed) that the ejbStore method hasn't been called on the |original bean yet so the SQL in the finder method doesn't find it in the |database. If I then execute the finder method outside of that transaction |it works fine, but I really need this to all work in the one transaction |so I can roll it back if there are any problems. | |Is there any way to force an ejbStore to occur in the middle of a |transaction? That way the update I've made is added to the database |transaction context and will show up in the finder methods select |statement. Yes there is, just hack your interceptor *for that particular bean* and declare a stack that includes it.. fairly straightforward, look at what the "container sync" does so that you can intercept on invoke and do the same logic... it is a custom interceptor that you would deploy ONLY for the bean marc | |Thanks, |Todd | | | |___ |JBoss-user mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
