Re: Alternatives to ACID, non-serialized concurrent transactions?

Todd Bandrowsky wrote:
> Yeah, I suppose the classic answer would be that these would be
> separate tables, but I'm wondering if there is not something more that
> could be done. Sometimes as I do SQL I wonder if I am working on
> making a wheelock more efficient when someone really just needs to
> invent the cartridge!

The problem with SQL:
It's not built for single objects and it can become difficult to specify what belongs to an object. There are no objects just relations.

> > I am thinking about a "locking-by-example" concept:
> > You construct a graph of objects as an example to describe the depth
> > of objects and all the child objects that are to be locked. This
> > "lock all as the example" could be applied to a query result.
>
> That is very interesting. To take it even further, we could assign
> terms to varying common graph operations, and we might wind up with
> lock by expression. Does any database implement that?

Sure:
Oracle supports "select [x] for update;"

Replace [x] with the joins, coalesce, group and where clauses you wish.

Your statement may just become very complex.

Kind regards,
Carl

--
Carl Rosenberger
db4o - database for objects - http://www.db4o.com