Prev: Missing db2tcpcm process
Next: CREATE DATABASE returns SQL ERROR SQL0101N
From: Mark A on 23 Jun 2010 08:32
"Ian" <ianbjor(a)mobileaudio.com> wrote in message
news:1a36f129-8743-4579-a0f1-ee26f7047d1e(a)z8g2000yqz.googlegroups.com...
> 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.


From: Frederik Engelen on 23 Jun 2010 09:58
On Jun 23, 2:32 pm, "Mark A" <no...(a)nowhere.com> wrote:
> "Ian" <ianb...(a)mobileaudio.com> wrote in message
>
> news:1a36f129-8743-4579-a0f1-ee26f7047d1e(a)z8g2000yqz.googlegroups.com...
>
> > 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.

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


From: Mark A on 23 Jun 2010 10:17
"Frederik Engelen" <engelenfrederik(a)gmail.com> wrote in message
news:5126fd99-1865-4c07-8eae-db5c0b8f172c(a)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).



First  |  Prev  | 
Pages: 1 2
Prev: Missing db2tcpcm process
Next: CREATE DATABASE returns SQL ERROR SQL0101N