-dain
On Thursday, April 3, 2003, at 04:22 AM, Stephen Coy wrote:
I'll add the testcase to Branch_3_0 as well.
We've never experienced this problem, but have only operated under 3.0.2, 3.0.4 and 3.0.6.
Our application (over)uses lots of CMR and we use those read-only tags everywhere too.
Steve Coy
On Thursday, April 3, 2003, at 07:03 PM, Andrew May wrote:
My test case fails on 3.0.3 so it's not just a problem with 3.2.0. So for us that means we can't go live with either :( - unless we can find a suitable workaround.
Andrew
Stephen Coy wrote:At the moment, we have a regression failure from 3.0.x to 3.2.0, because it "works" fine there. I say it "works" because it doesn't fail, which is not the same thing as behaving correctly.
So, we need to decide what the appropriate behaviour will be for 3.2 and make it work properly.
I will get the testcase as it stands cleaned up and checked in tonight.
At the moment, if people try to migrate from 3.0.x to 3.2, their applications will break if using this construct.
Steve Coy
On Thursday, April 3, 2003, at 03:58 AM, Dain Sundstrom wrote:I doubt that a CMR will work with the read-only flag. The problem is a read-only specifically does not associate the transaction with the invocation and does not enlist the entity in the tx synchronization. A CMR collection is dependent on a transaction and having tx synchronization. I bet Stephen can hack the code to get it to work, but should we fix it or just disallow it for CMRs?
I personally have never liked the read-only flag because it means so much in out system. It means no-lock, no-transaction, no-synchronization, and so on. What if I want the read in a transaction because I want consistent reads across several entities, but I want to avoid a sync lock? Because all of these option are tied up into a single flag we don't get flexibility.
In JB4 CMP the flag has little value because we will have notification from fields when something changes. In this case read-only would mean no-lock and no-transaction, but is that what the average user thinks read-only would mean. Even worse it ends up being a fairly small optimization. Since a local transaction has almost no overhead, and for JB4 we plan on making multi-instance the default you get 0 benefit from the flag, but a ton of headache from the code. I think for 4.0 we should not allow read-only for CMP. For BMP is makes since, but I think we should make it mean just no-store or change it to no-store. Additionally we I think we should add a no-lock flag for single-instance invocations. For no-transaction we have the standard EJB flags.
-dain
On Wednesday, April 2, 2003, at 10:18 AM, Stephen Coy wrote:
Ah ha!
It needs those "read-only" tags in jboss.xml in order to fail.
Previously, I had explicitly specified that "getChildren" was read-only. It needs to be "get*".
My test is failing now.
Steve Coy
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
