Hi Lukas,
Related issue, but not the same as I had started with...
I'm using MVCC mode in the database. So as my understanding has it, the
optimistic locking may not work quite as expected. If the writing of the
records happens in concurrent transactions, then each will write
successfully (as they are reading their own version of record), but on
commit the (2nd?) transaction will throw an exception because the
underlying database will not accept the commit. Which is fine, it still
means it did it's job, but it will be a different exception to the JOOQ
optimistic locking exception.
Or so is my understanding of how MVCC works.
Just thinking it adds to the reasons not too put extra "smarts" into
JOOQ. I could turn MVCC off, but I pretty much rely on it to avoid
deadlocks.
Also, with MVCC on, the FOR UPDATE on the optimistic locks is not really
needed. It just adds potential for deadlocks for me :). Tables are
always locked in the same order (well they should be!), so it should be
fine.
I just wanted to mention it as I thought it relevant to the discussion.
Thanks, Ryan
On 25/02/2013 10:10 PM, Lukas Eder wrote:
With the DataTable, you can also run queries on it, sort it, define parent
child relationships (aka Foreign Key) with other data tables, it stores
history of changes, create views of it, have listeners on data change (I
think). It is like an in memory database pretty much. I think the
similarities to a JDBC result set end at the idea of having rows and
columns.
I see. Well, I have no plans just yet, of implementing an in-memory
database cache ;-) I guess, in the whole LINQ world, blending
in-memory C# / VB.NET tables with actual SQL Server tables starts
making sense, though.
I don't think a DataTable works in "eager" mode. It works offline, a
changeset is calculated and applied to the database.
Yes, good luck with concurrency, there :-)
Bear in mind I haven't used this for about 6 years :), but I often find a
lot of good ideas in the .Net world. Even if my preference is Java.
Yes, I agree.
Regaring the .remove() functionality you mentioned, I've implemented
something similar in my project where records not yet in the database, if
.remove() is called they are just discarded client side. If they are in the
database, then the .remove() when flushed will execute a DELETE on the
database (first with an optimistic locking check). This kind of
functionality built in would be great. It would save implementing all the
logic and "tracking" my records.
Sounds good. Although you'll still have to track *some* data, because
of jOOQ being unaware of transaction rollbacks...
Cheers
Lukas
--
You received this message because you are subscribed to the Google Groups "jOOQ User
Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
