You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Raghuram Rajah <ra...@s1.com> on 2002/12/22 16:27:12 UTC
RE: default isolation level
Please be careful about managed environments. You should not call
setTransactionIsolation from within a JTA transaction. I would much rather
allow an API to modify the isolation level and allow the user to set the
isolation level, if he so chooses to. Otherwise, we should leave it at the
isolation level set either through the driver's defaultIsolationLevel or
through ejb's isolation specification. I would prefer OJB not to set any
isolation level explicitly.
My two cents...
Raghu.
-----Original Message-----
From: Oleg Nitz
To: OJB Developers List
Sent: 12/22/2002 12:03 PM
Subject: default isolation level
Hi All,
I've noticed that OJB seems to use READ_UNCOMMITTED isolation level by
default. But
1) AFAIK with READ_COMMITTED isolation level database server works much
faster, at least this is true for Sybase ASE. I suppose that for
READ_UNCOMMITTED level table indices can't be used at all because they
are
updated on commit, so any query on uncommitted data requires full table
scans, for queries with joins on big tables the difference of execution
time
with READ_COMMITTED and with READ_UNCOMMITTED is amazing.
2) I haven't found any setTransactionIsolation() calls in OJB code, so I
suppose that isolation-level attribute in repository.xml is simply
ignored
now, OJB works always in READ_COMMITTED mode, which is good for
performance
:-)
So I propose to fix 2) and to set level to READ_COMMITTED by default.
I could do this.
Regards,
Oleg
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
Re: default isolation level
Posted by David Jencks <da...@directvinternet.com>.
transaction isolation level is really part of an EIS system properties and
may be quite EIS specific. As such it is not part of the ejb spec. I
certainly agree that attempting to change tx isolation within a jta tx is
unlikely to produce usable results.
I think the most appropriate way to deal with this in a managed environment
is to:
deploy ojb as a j2ee connector
set the tx isolation level as a ManagedConnectionFactory config-property.
In the absense of a connector version of ojb, setting it as a config
property for the ojb services as a whole seems appropriate. Modifying the
tx isolation in application code is likely to prove unsatisfactory.
thanks
david jencks
On 2002.12.22 10:27:12 -0500 Raghuram Rajah wrote:
> Please be careful about managed environments. You should not call
> setTransactionIsolation from within a JTA transaction. I would much
> rather
> allow an API to modify the isolation level and allow the user to set the
> isolation level, if he so chooses to. Otherwise, we should leave it at
> the
> isolation level set either through the driver's defaultIsolationLevel or
> through ejb's isolation specification. I would prefer OJB not to set any
> isolation level explicitly.
>
> My two cents...
>
> Raghu.
>
> -----Original Message-----
> From: Oleg Nitz
> To: OJB Developers List
> Sent: 12/22/2002 12:03 PM
> Subject: default isolation level
>
> Hi All,
>
> I've noticed that OJB seems to use READ_UNCOMMITTED isolation level by
> default. But
> 1) AFAIK with READ_COMMITTED isolation level database server works much
> faster, at least this is true for Sybase ASE. I suppose that for
> READ_UNCOMMITTED level table indices can't be used at all because they
> are
> updated on commit, so any query on uncommitted data requires full table
> scans, for queries with joins on big tables the difference of execution
> time
> with READ_COMMITTED and with READ_UNCOMMITTED is amazing.
> 2) I haven't found any setTransactionIsolation() calls in OJB code, so I
>
> suppose that isolation-level attribute in repository.xml is simply
> ignored
> now, OJB works always in READ_COMMITTED mode, which is good for
> performance
> :-)
>
> So I propose to fix 2) and to set level to READ_COMMITTED by default.
> I could do this.
>
> Regards,
> Oleg
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
Re: default isolation level
Posted by Oleg Nitz <on...@ukr.net>.
Hi Raghu,
I agree with you. Maybe we need some special value of "isolation-level"
attribute in repository.xml, something like "default" or "none"?
Oleg
On Sunday 22 December 2002 15:27, you wrote:
> Please be careful about managed environments. You should not call
> setTransactionIsolation from within a JTA transaction. I would much rather
> allow an API to modify the isolation level and allow the user to set the
> isolation level, if he so chooses to. Otherwise, we should leave it at the
> isolation level set either through the driver's defaultIsolationLevel or
> through ejb's isolation specification. I would prefer OJB not to set any
> isolation level explicitly.
>
> My two cents...
>
> Raghu.
>
> -----Original Message-----
> From: Oleg Nitz
> To: OJB Developers List
> Sent: 12/22/2002 12:03 PM
> Subject: default isolation level
>
> Hi All,
>
> I've noticed that OJB seems to use READ_UNCOMMITTED isolation level by
> default. But
> 1) AFAIK with READ_COMMITTED isolation level database server works much
> faster, at least this is true for Sybase ASE. I suppose that for
> READ_UNCOMMITTED level table indices can't be used at all because they
> are
> updated on commit, so any query on uncommitted data requires full table
> scans, for queries with joins on big tables the difference of execution
> time
> with READ_COMMITTED and with READ_UNCOMMITTED is amazing.
> 2) I haven't found any setTransactionIsolation() calls in OJB code, so I
>
> suppose that isolation-level attribute in repository.xml is simply
> ignored
> now, OJB works always in READ_COMMITTED mode, which is good for
> performance
>
> :-)
>
> So I propose to fix 2) and to set level to READ_COMMITTED by default.
> I could do this.
>
> Regards,
> Oleg