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
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
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
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
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
-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
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
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
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
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
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
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
-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
|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
|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
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
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
|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
|
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]
-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
|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
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]
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
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
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
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 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
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
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
|
| -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
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
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
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
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
|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]
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
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
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
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
-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
? 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
-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
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.
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
-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
| 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
: [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
- 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
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
|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
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
|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
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]
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
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
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...
-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
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
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
|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
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
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
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
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
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
65 matches
Mail list logo
