If the write is Isolated from a read then should a read really be allowed to cause a concurrency failure on the write?  The read only needs to be guaranteed to not see the table in a partial/incomplete state and the write's changes are isolated until it commits.   A read conflicting with a write seems like something altogether different than a write conflicting with another write.

Am I missing something here?

73,
Matthew W. Jones (KI4ZIB)
http://matburt.net


On Wed, Sep 2, 2009 at 4:16 PM, Stefan Manegold <Stefan.Manegold@cwi.nl> wrote:
On Wed, Sep 02, 2009 at 04:03:17PM -0400, Matthew Jones wrote:
> Are you saying that if someone reads data from a table while another
> transaction is bulk-loading data that that will cause a concurrency conflict
> and a forced rollback?
>
> I'm looking at the behavior of one of my long running batch loads and that
> looks to be the case... if so, that seems pretty extreme.   I could
> understand protecting from simultaneous modification but it seems wrong to
> cause a write to fail for any read on a table.

writes conflict with reads, and reads with writes, just as writes conflict
with writes; only multiple concurrent reads do not conlict with each other.

Stefan

> 73,
> Matthew W. Jones (KI4ZIB)
> http://matburt.net
>
>
> On Wed, Sep 2, 2009 at 3:41 PM, Martin Kersten <Martin.Kersten@cwi.nl>wrote:
>
> > Matthew Jones wrote:
> > > There's no relational data in these tables, I guess I just need
> > > something internal to manage concurrency... like blocking table locks so
> > > I don't have to wait for a failure in order to manage concurrency on my
> > own.
> > you either have to serialize the updates/access at your client interface,
> > or hook into the MAL kernel to get access to the general lock/semaphore
> > module.
> >
> > >
> > > I noticed in one of my operations  which was a single update to a table
> > > that no other processes were using that it gave me that error, informed
> > Optimistic concurrency control should also ensure that non of the
> > concurrent
> > transactions reads stale data.
> > This becomes tricky if you have multiple user sessions with both autocommit
> > and compound transactions, because then the timespans to trigger
> > a transaction failure are larger.
> >
> > > me of the rollback, but the changes still took effect.... which is
> > > alarming since I will now need to:
> > >
> > > 1) Try the operation
> > > 2) If it fails, check to see if the change actually took effect
> > > 3) if the changes didn't take effect re-try the operation
> > >
> > > This is disconcerting.
> > >
> > > 73,
> > > Matthew W. Jones (KI4ZIB)
> > > http://matburt.net
> > >
> > >
> > > On Wed, Sep 2, 2009 at 3:02 PM, Martin Kersten <Martin.Kersten@cwi.nl
> > > <mailto:Martin.Kersten@cwi.nl>> wrote:
> > >
> > >     Dear Matthew,
> > >
> > >     A quick initial reaction. MonetDB uses an optimistic concurrency
> > control
> > >     scheme, which is geared at high-read, low-write applications. If you
> > hit
> > >     the system with multiple concurrent writes on the same table, then
> > >     indeed
> > >     to secure acid properties, transactions are bound to fail. MonetDB
> > >     indeed
> > >     conforms to the semantics of a transaction safe system.
> > >
> > >     Blocking queries is equivalent to relation level locking.
> > >     This is not the preferred way to go for the kernel, because someone
> > >     will immediately ask for more granularities and als relaxation of
> > >     the ACID principles.
> > >
> > >     There are several application scenarios to deal with this issue,
> > >     but all depend on the semantics required.
> > >
> > >     regards, Martin
> > >
> > >     Matthew Jones wrote:
> > >      > I have multiple processes reading and writing to the same table
> > >     and I've
> > >      > noticed really persistent concurrency problems:
> > >      >
> > >      >   File "/usr/lib/python2.5/site-packages/monetdb/sql/cursors.py",
> > >     line
> > >      > 208, in execute
> > >      >     self.__store_result(block)
> > >      >   File "/usr/lib/python2.5/site-packages/monetdb/sql/cursors.py",
> > >     line
> > >      > 520, in __store_result
> > >      >     self.__exception_handler(InterfaceError, "Unknown state, %s"
> > >     % block)
> > >      >   File "/usr/lib/python2.5/site-packages/monetdb/sql/cursors.py",
> > >     line
> > >      > 574, in __exception_handler
> > >      >     raise exception_class(message)
> > >      > InterfaceError: Unknown state, &2 65541 -1
> > >      > !ERROR: COMMIT: transaction is aborted because of concurency
> > >     conflicts,
> > >      > will ROLLBACK instead
> > >      >
> > >      > I'm not sure what the problem is, but it exists in such a way
> > >     that all
> > >      > operations that load or update information in MonetDB have to be
> > put
> > >      > into a loop to continuously retry.
> > >      >
> > >      > I'm using autocommit, but I would expect MonetDB to handle
> > >     concurrency
> > >      > issues in a decent way, like maybe blocking a query until the
> > other
> > >      > query finished.  I'm not clobbering data, most of these are just
> > bulk
> > >      > load operations that insert new rows.
> > >      >
> > >      > Is there any way to address this issue without having to putting
> > >     retry
> > >      > loops around all of the code I'm writing to write to the database?
> > >      >
> > >      > 73,
> > >      > Matthew W. Jones (KI4ZIB)
> > >      > http://matburt.net
> > >      >
> > >      >
> > >      >
> > >
> > ------------------------------------------------------------------------
> > >      >
> > >      >
> > >
> > ------------------------------------------------------------------------------
> > >      > Let Crystal Reports handle the reporting - Free Crystal Reports
> > >     2008 30-Day
> > >      > trial. Simplify your report design, integration and deployment -
> > >     and focus on
> > >      > what you do best, core application coding. Discover what's new
> > with
> > >      > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > >      >
> > >      >
> > >      >
> > >
> > ------------------------------------------------------------------------
> > >      >
> > >      > _______________________________________________
> > >      > MonetDB-users mailing list
> > >      > MonetDB-users@lists.sourceforge.net
> > >     <mailto:MonetDB-users@lists.sourceforge.net>
> > >      > https://lists.sourceforge.net/lists/listinfo/monetdb-users
> > >
> > >
> > >
> > ------------------------------------------------------------------------------
> > >     Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > >     30-Day
> > >     trial. Simplify your report design, integration and deployment - and
> > >     focus on
> > >     what you do best, core application coding. Discover what's new with
> > >     Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > >     _______________________________________________
> > >     MonetDB-users mailing list
> > >     MonetDB-users@lists.sourceforge.net
> > >     <mailto:MonetDB-users@lists.sourceforge.net>
> > >     https://lists.sourceforge.net/lists/listinfo/monetdb-users
> > >
> > >
> > >
> > > ------------------------------------------------------------------------
> > >
> > >
> > ------------------------------------------------------------------------------
> > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > 30-Day
> > > trial. Simplify your report design, integration and deployment - and
> > focus on
> > > what you do best, core application coding. Discover what's new with
> > > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > >
> > >
> > > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > MonetDB-users mailing list
> > > MonetDB-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/monetdb-users
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> > trial. Simplify your report design, integration and deployment - and focus
> > on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > MonetDB-users mailing list
> > MonetDB-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/monetdb-users
> >

> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> MonetDB-users mailing list
> MonetDB-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/monetdb-users


--
| Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl |
| CWI,  P.O.Box 94079 | http://www.cwi.nl/~manegold/  |
| 1090 GB Amsterdam   | Tel.: +31 (20) 592-4212       |
| The Netherlands     | Fax : +31 (20) 592-4312       |

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MonetDB-users mailing list
MonetDB-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/monetdb-users