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
>
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
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 c
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 ea
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
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 th
01 5:19 AM
Subject: RE: [JBoss-dev] High load...
> |I think you missed one of the old messages (way to many today).
> |
> |It appears that if you changes the transaction isolation in the middle of
a
> |transaction the driver can perform an implicit commit (YUCK).
> |
> |So, I don'
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 o
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
tr
On 2001.06.27 10:55:10 -0400 Bill Burke wrote:
>
>
> > >
> > > |
> > > |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.setI
> -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
Hi,
On 2001.06.26 23:30:32 -0400 marc fleury wrote:
> |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 cle
Hi, the algorithm is in the post marc was replying to.
Here it is again, with garbage collection instructions and referring to
entities rather than records.
transactions are numbered sequentially when they are started.
Each entity (version) includes the transaction id of the last change to it
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> fleury
> Sent: Tuesday, June 26, 2001 11:37 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] High load...
>
>
> |> Sure, it would be useful to be abl
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
-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, but
gt;To: <[EMAIL PROTECTED]>
>Subject: RE: [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
|> 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
|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 to
what we do = (does a jdbc connection support setting iso
> -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:
> >
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
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 in
> -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 with
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]
> >
> -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 i
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"
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,
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 swit
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
|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]
http://lists.sourceforge.n
t: Tuesday, June 26, 2001 5:38 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.
>
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 f
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
mitted.
|>
|> Bill
|>
|>
|>>-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,
On 2001.06.26 16:45:46 -0400 marc fleury wrote:
> |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 start
are just fine with read_committed.
>
> Bill
>
>
>>-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: [JBo
ment,
marcf
|
|Bill
|
|> -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,
|>
|> Forgi
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
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
> H
|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 la
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
Hi,
On 2001.06.26 11:24:43 -0400 Georg Rehfeld wrote:
> 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
> >>>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
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
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?
>>
>>
> fixed
>
Like at compile time, literally 'static' in the java sense static?
Please god,
Bill Burke wrote:
>
>
> Isolation levels and locking are really orthonogal, aren't they?
The isolation level is really a hint to the DB as to how you want to lock.
>
>
>>|All in all, I think JBOSS should delegate synching and locking to the DB
>>
>>sure but my point is that can be a cache
> >
> > 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]
http://lists.sourcef
|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 lo
> -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 wa
> |I added transaction isolation to the new cmp plugin. You can set it by
> |adding the element after the datasource element.
> |Valid levels are:
> |transaction-none
> |transaction-read-committed
> |transaction-read-uncommitted
> |transaction-repeatable-read
> |transaction-s
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]
http://lists
Done.. It is now in both JAWS and JBossCMP.
-dain
- Original Message -
From: "Dain Sundstrom" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 26, 2001 1:19 PM
Subject: Re: [JBoss-dev] High load...
> > we would have to implement the transactio
|I added transaction isolation to the new cmp plugin. You can set it by
|adding the element after the datasource element.
|Valid levels are:
|transaction-none
|transaction-read-committed
|transaction-read-uncommitted
|transaction-repeatable-read
|transaction-serializable
|
|G
> 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
n 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...
> -
|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
|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 DB
> -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:
> > |- S
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-
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
> >
> > 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 growi
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 jus
> >>>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
> >>
> >>
>
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
>>
>>
>
> Exac
> > 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 ca
|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
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
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
|co
> -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.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of danch
> (Dan Christopherson)
> Sent: Monday, June 25, 2001 1:34 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] High load...
>
>
> marc fleury 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 (i.e., bean data
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
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 alway
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
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]
http://lists.s
|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
> 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.
>
Will this affect commit Option A and B, which doesn't passivate? I'm
curious because in the
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
|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
marc,
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. Othe
80 matches
Mail list logo
