Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
-
None
Description
I was loading data into Cassandra, and tried to select from it at the same time. I got the following:
MariaDB [test]> show processlist;
|
+----+------+-----------------+------+---------+------+------------------------------+------------------------------------------------------------------------------------------------------+----------+
|
| Id | User | Host | db | Command | Time | State | Info | Progress |
|
+----+------+-----------------+------+---------+------+------------------------------+------------------------------------------------------------------------------------------------------+----------+
|
| 1 | root | localhost | dbt3 | Sleep | 1983 | | NULL | 0.000 |
|
| 2 | root | localhost:38568 | dbt3 | Query | 326 | reading file | LOAD DATA INFILE '/home/ubuntu/dbt3-1.9/s1-cassandra/lineitem.tbl' into table lineitem fields termin | 14.660 |
|
| 3 | root | localhost:38587 | dbt3 | Query | 144 | Waiting for table level lock | select * from lineitem limit 1 | 0.000 |
|
| 4 | root | localhost:38590 | test | Query | 0 | NULL | show processlist | 0.000 |
|
+----+------+-----------------+------+---------+------+------------------------------+------------------------------------------------------------------------------------------------------+----------+
|
Is the engine too strict on locking?
Attachments
Issue Links
- is part of
-
MDEV-431 Cassandra storage engine
-
- Closed
-
Activity
This is wrong, because it's a limitation that doesn't make sense. MyISAM is a local, non-transactional storage. If you lock a MyISAM table, you can then make updates and be sure no one has interfered with them.
Cassandra is a remote storage. There is no way to make sure that nobody has accessed the row you've just read. Why restrict updates from the local server, then?
Also, cassandra's data model and architecture show systematic avoidance of any kinds of locking. For example, update operations are specifically designed to be interchangeable (the one with greater timestamp wins). Counters have a special implementation that accepts increment/decrement operation, instead of the usual "lock; modify; unlock" way, etc.
Why is it wrong? You'd have the same with, say, a MyISAM table.
Or is there a plan to allow row-locking for the Cassandra engine?