I Have been annoyed by this problem as well. This is caused by someone who
is subscribed having their mail stopped by their own mail system, which
then complaines to the sender.
In general, its good form for a mail administraor to warn senders if they
intercept their mail. However, a sender
spam warning test
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
--- Juha Lindfors [EMAIL PROTECTED] wrote: At 17:26
5.6.2001 +0100, you wrote:
I have checked in a JBoss-2.2.2_Jetty-3.1.RC5.tgz
bundle into the CVS binaries module (late last
night).
How do I get this copied across to the release
area,
and update
Dan Ch,
Was this part of the 2.2.2 release. I actually had issues with the load
[it was screwing up the columns] because their order in the resultset and in
the iterator for getCMPFields was different. Actually got all that to work
when I saw this update from you! Anyway, just wanted to
Hi,
First of all, thanks for the contribution. Things get done when
people jump in and contribute their time, and we definitely have a
scaling problem we need to fix.
If I understand the implications of your code, I'm very against this
particular solution, as it is a violation of the EJB
My view is if the new option to have multiple bean instances is going to
take long to write why should we be bothered about concurrency in a read
only bean?
Vinay
- Original Message -
From: Dan OConnor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 1:26 PM
Hi Vinay,
see below
In order to avoid locking for TX or CTX in the
EntityInstanceInterceptor, I've basically added a flag to
indicate whether the bean can be optimized for read only
operation. In the EntityInstanceInterceptor, where the loop
actually wait for the lock I've added a
Hi Marc,
When you were here in London
we'd discussed adding functionality to use things like ROWID for fast updates
and deletes [as opposed to using primary keys]. I have been able to implement
this by
1. Adding a field in jaws.xml called rowid-column
name. This is ROWID for Oracle and
User: sparre
Date: 01/06/06 07:23:26
Modified:src/bin ctstest.bat ctstest.sh
Log:
Fixed standalone CTS test.
Revision ChangesPath
1.8 +1 -1 jbosstest/src/bin/ctstest.bat
Index: ctstest.bat
Dan Ch,
Have not submitted the patch as yet. I'll check it in once people think
its alright. Do you want me to send you complete source files for the
changes?
Vinay
- Original Message -
From: danch [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 6:17 PM
Phew! I spent a couple of hours trying to figure out what problem was
because I was doing the ROWID bit and was wondering where on earth the
values were getting mixed up!!!
Vinay
- Original Message -
From: danch [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 6:14
Locks will be in place since the rowid stuff is applicable only for updates
and deletes. selects obviously cannot work with this! Also, to the best of
my knowledge Oracle row ids are fixed unless you move them to new db i.e.
export or stuff.
Vinay
- Original Message -
From: Georg
Bugs item #430691, was updated on 2001-06-06 07:53
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=430691group_id=22866
Category: JBossServer
Group: v2.2.2 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Pete Halverson (halversp)
Assigned
User: sparre
Date: 01/06/06 08:30:31
Modified:src/build/subprojects build-testbean.xml
Log:
Fixed standalone testbean test.
Revision ChangesPath
1.2 +1 -0 jbosstest/src/build/subprojects/build-testbean.xml
Index: build-testbean.xml
User: sparre
Date: 01/06/06 08:42:46
Modified:src/bin hellotest.bat hellotest.sh
Log:
Fixed unneeded standalone hello-test dependency on testbean-test.
Revision ChangesPath
1.3 +1 -1 jbosstest/src/bin/hellotest.bat
Index: hellotest.bat
User: sparre
Date: 01/06/06 08:48:57
Modified:src/bin bmptest.sh
Log:
Fixed unneeded standalone bmp-test dependency on testbean-test.
Revision ChangesPath
1.4 +1 -1 jbosstest/src/bin/bmptest.sh
Index: bmptest.sh
I suppose it would get us out of the problem of being certified as J2EE
compliant as well...
-Original Message-
From: K.V. Vinay Menon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 06, 2001 11:46 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
OK!
I know that it is kind of controversial and that its spec violation and
stuff but why can't we have multi threaded beans for read-only cases? Why
should we be bothered about transactions? We don't lock the database for
selects do we? Non-purists who face real world performance issues -
Use insert ... returning rowid into ?
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 06, 2001 12:02 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Fast Updates Based on Row ID
Hi,
I may be wrong about oracle rowid changing on row update, it's
It may well be usefull, but does this behavior belong in the normal
EntityInstanceInterceptor? Why not just implement an non-blocking
variant of EntityInstanceInterceptor, and reconfigure your stack in
jboss.xml?
K.V. Vinay Menon wrote:
OK!
I know that it is kind of controversial and
Bill Burke wrote:
- What's wrong with doing a Context lock, but not doing a transactional lock
for read-only beans?
won't you still block on the context lock?
If you do this you'll still be spec compliant,
correct? How would this affect your performance results? I'm pretty sure
the
User: alborini
Date: 01/06/06 10:13:42
Modified:business cvs.html
Log:
Added missing (new) cvs modules.
Revision ChangesPath
1.12 +3 -0 newsite/business/cvs.html
Index: cvs.html
===
RCS
danch (Dan Christopherson) wrote:
Georg Rehfeld wrote:
One problem here is that when we're waiting on the context, we want to
wait on the context (i.e. ctx.wait(DEADLOCKTIMEOUT + 1000)) Just doing
wait and notifyAll on the interceptor itself will involve all calls on
our entity
Bugs item #430771, was updated on 2001-06-06 10:47
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=430771group_id=22866
Category: None
Group: v2.2.2 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to:
User: azakkerman
Date: 01/06/06 10:48:29
Modified:src/main/org/jboss/tm/plugins/tyrex CoordinatorInvoker.java
CoordinatorRemote.java ResourceInvoker.java
TyrexTxPropagationContext.java
Log:
Bug fix in ResourceRemote to return the Vote
Well,
We are an Oracle shop and woudl benefit [like loads of other Oracle
users] from these changes. Remember they are there as an option. If you
choose not to use them JAWS will work as usual.
Vinay
- Original Message -
From: Jay Walters [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent:
User: alborini
Date: 01/06/06 11:08:48
Modified:business binary.html
Log:
Correct links and info for jboss/jetty package
Revision ChangesPath
1.22 +9 -9 newsite/business/binary.html
Index: binary.html
I remember Marc talking about this issue awhile back. He said the best
performance would be to have the wait within a loop with a 5 second wait.
while (!locked()) // pseudo code
{
this.wait(5000);
if (!locked())
{
log.(LOCKING-WAITING);
}
}
Regards,
Bill
Very true!
I could do that. That way folks who want to use it can use it.
Vinay
- Original Message -
From: danch (Dan Christopherson) [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 5:37 PM
Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
It may well
So do you build all your other applications to use rowid?
-Original Message-
From: K.V. Vinay Menon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 06, 2001 1:59 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Fast Updates Based on Row ID
Well,
We are an Oracle shop and woudl
Bill Burke wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Georg
Rehfeld
Sent: Wednesday, June 06, 2001 1:11 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Hello Bill, hi all,
- What's wrong with doing a
Just for the record, I don't mind having Oracle specific optimizations
in JAWS, it's just that the current structure of JAWS does not really
lend itself to this. Also, if you do use Oracle specific stuff for this
optimization, the option in a jaws entity should be given a name that
will tell
It's not this same. Basically you have a loop to check to see if the
transaction has been commited or unlocked, but you put a wait of 5 seconds
in there. After the 5 seconds if you're still not locked loop again.
OT, how does transaction timeout destroy the thread? TIA.
Bill
-Original
Jay,
No. Not really. Its is just that the new Oracle release clearly state
advantages of using rowids for updates and it is very attractive to have
that kind of a facility for updates and deletes on huge tables [we do have
quite a few tables that are in excess of 5-6 million records]. The
I don't understand what is different between the two. Are you saying to
have only one place where we wait? If so I agree.
Bill Burke wrote:
It's not this same. Basically you have a loop to check to see if the
transaction has been commited or unlocked, but you put a wait of 5 seconds
in
To be honest if the response time for a lookup is 5 seconds your clients
would go shopping elsewhere!
Vinay
- Original Message -
From: danch (Dan Christopherson) [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 9:48 PM
Subject: Re: Missing wait/notify (was Re:
Dan Ch,
Well as you might have noticed the code will work as usual if the
rowid-column field is not specified in jaws.xml. If it is specified, it will
then be used instead of the primary key. I am not sure of how other
databases work with rowids which is why jaws will still default to normal
Just to confirm what Jay is saying...
I was recently at an Oracle workshop, and since the
rowid isn't part of the ANSI SQL standard and is a
proprietary pseudo column, they warned us again using
it in building applications. They said, the
improvements could be wiped out in a future release of
User: jules_gosnell
Date: 01/06/06 15:45:25
Modified:jetty/etc run.sh
Log:
Solaris 'sh' does not seem to like '-L'
Revision ChangesPath
1.3 +1 -1 contrib/jetty/etc/run.sh
Index: run.sh
===
Certification ceases to make any business sense when performance sucks! The
customer is not bothered if you are running a J-2-E-E compliant / certified
app server. They are not even bothered if you use Java or COBOL as long as
they get what they want - a good user experience.At some point we have
And is Marc is in his alien space suit?!
Vinay
- Original Message -
From: Bordet, Simone [EMAIL PROTECTED]
To: JBoss Development Mailing List (E-mail)
[EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 5:36 AM
Subject: [JBoss-dev] JBOSS at JAVAONE
Hello everybody,
JBoss *is* at
Dear Vinay,
No. Not really. Its is just that the new Oracle release clearly state
advantages of using rowids for updates and it is very attractive to have
that kind of a facility for updates and deletes on huge tables [we do have
quite a few tables that are in excess of 5-6 million
Hello Gerald,
While following the recent LOCKING-WAITING threads I've been
experimenting/tuning my beans for concurrency by turning reentrant on and
setting TX_SUPPORTS. Great improvement!
Ah, at least one person giving it a try, thanks. I should have
done this on my own, but I'm just too
Sorry my pseudo code was sooo confusing.
Here's something better
synchronized(ctx)
{
while (ctx.isLocked()) {
ctx.wait(5000);
if (ctx.isLocked()) {
log.log(LOCKING-WAITING);
}
else
JBoss daily test results
SUMMARY
Number of tests run: 68
Successful tests: 57
Errors:1
Failures: 10
[time of test: 7 June 2001 2:45]
See http://lubega.com for
If I wanted to write
a NoCachePolicy for EntityBeans (that is, no entity instance caching).
Would it be as simple as implementing CachePolicy where get(..) just returns
null?
TIA,
Bill
OK, I think we're talking about the same sort of thing. This looks good.
Bill Burke wrote:
Sorry my pseudo code was sooo confusing.
Here's something better
synchronized(ctx)
{
while (ctx.isLocked()) {
ctx.wait(5000);
if (ctx.isLocked())
K.V. Vinay Menon wrote:
To be honest if the response time for a lookup is 5 seconds your clients
would go shopping elsewhere!
5 seconds is the worst case: normally you'll be notified long before
that happens. Actually 5 seconds is so much worst case that that's
probably about the point
If you do this then maybe you can extend the patch to include the
insert...returning construct Just say you need Oracle8 to use this
feature.
Maybe you could also modify the SQL to not change the primary key field.
I'll bet if you use a lot of referential integrity constraints this will
Feature Requests item #430946, was updated on 2001-06-06 22:25
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376688aid=430946group_id=22866
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Marco Hunsicker (marcohu)
Assigned to: Nobody/Anonymous
50 matches
Mail list logo
