Data Studion and autocommit
peteh
Is it possible to configure autocommit in Data Studio SQL processor? I
can't find this feature anywhere... Kind of a show-stopper for us
using the tool productively. Any insight greatly appreciated
Pete H
Ian
I don't think this is possible (at least with 2.2.0.2). There's no
option to set this, and I don't believe that there is not a JDBC
property that you can set at the connection level to disable this. I
even tried setting autoCommit=false in the Optional Driver Properties
for a particular connection, but this doesn't work.
Mark A
news:acc6ef6f-56cf-4a69...@b35g2000yqi.googlegroups.com...
> I don't think this is possible (at least with 2.2.0.2). There's no
> option to set this, and I don't believe that there is not a JDBC
> property that you can set at the connection level to disable this. I
> even tried setting autoCommit=false in the Optional Driver Properties
> for a particular connection, but this doesn't work.
Thank God for this. Bless you, Data Studio developers.
Any decent DBA should know how to run a script with autocommit off. This
information should never be provided to developers or end users.
marichu
> "Ian" <ianb...@mobileaudio.com> wrote in message
Hi all,
The autocommit capability is not JDBC property but is a method call
against the connection. Therefore, it cannot be specified in the
Optional Driver Properties.
There is an open requirement to support this in future releases of
Data Studio / Optim Development Studio.
Ian
>
> news:acc6ef6f-56cf-4a69...@b35g2000yqi.googlegroups.com...
>
> Any decent DBA should know how to run a script with autocommit off. This
> information should never be provided to developers or end users.
Yes, of course. But the OP was asking if it's possbile to do it from
Data Studio.
Turning off autoCommit is a very valid request. Just because it's
powerful (and
can cause problems if not used with care) doesn't mean people
shouldn't be
able to use it.
Mark A
> Yes, of course. But the OP was asking if it's possbile to do it from Data
> Studio.
> Turning off autoCommit is a very valid request. Just because it's powerful
> (and
> can cause problems if not used with care) doesn't mean people shouldn't be
> able to use it.
It may be a valid request, but I would be willing to sacrfice the
convenience of not having it in the tool (would have to use command line)
for the benefit of keeping that feature out of the hands of my developers
and end-users, both of which use the tool for production databases. Even an
S lock that is not released causes a lot of problems. Just my opinion.
Frederik Engelen
> "Ian" <ianb...@mobileaudio.com> wrote in message
I think that's a bad idea, keeping it out of Data Studio for this
reason is simply security through obscurity. Any competent Java
developer can write and launch this in 5 minutes:
con.setAutoCommit(false);
stmt.executeUpdate("DELETE FROM STOCK WHERE ID=X");
Thread.sleep(100000);
worldCup.watch("Ghana", "Germany");
home.go();
work.return();
con.commit();
Protecting against this behaviour seems quite difficult. Maybe a
combination of WLM and NUM_LOG_SPAN might help, but I don't know the
golden bullet against this, besides whipping any offending
developers...
--
Frederik
Mark A
news:5126fd99-1865-4c07...@g19g2000yqc.googlegroups.com...
>I think that's a bad idea, keeping it out of Data Studio for this
> reason is simply security through obscurity. Any competent Java
> developer can write and launch this in 5 minutes:
>
> con.setAutoCommit(false);
> stmt.executeUpdate("DELETE FROM STOCK WHERE ID=X");
> Thread.sleep(100000);
> worldCup.watch("Ghana", "Germany");
> home.go();
> work.return();
> con.commit();
>
> Protecting against this behaviour seems quite difficult. Maybe a
> combination of WLM and NUM_LOG_SPAN might help, but I don't know the
> golden bullet against this, besides whipping any offending
> developers...
>
> --
> Frederik
I am actually not worried about updates, because they don't have authority
to update in production. But they do have authority to select in production,
and doing a select with auto-commit off will hold an S lock until it is
committed. That means no one else can update that row using the application
code.
I am also not worried about someone writing java code, I am more worried
about accidentally turning auto-commit off when browsing data. I don't think
these problems arise when someone intentionally does not commit (or at least
that is a different problem).
I would also like to see a "light" version of Data Studio that only
functions as a data query/update tool as opposed to a development or DBA
tool. Maybe this one could have the auto-commit always on (or not easily
changed).