2008/5/27 Adam Megacz <[EMAIL PROTECTED]>: > After further thought, one can do better: let each ResultSet have two > modes, called "normal" and "cached". When a ResultSet is moved > from the "normal" mode to the "cached" mode, it finishes all of its > sqlite step()s and stores the results internally, then closes the > statement. Now, whenever an executeUpdate() is performed, first > check if any "normal"-mode ResultSets are open on that table; if so, > force them into "cached" mode before initiating the update operation. > > This way, you pay the increased memory penalty only in the case > where you absolutely must (the case where sqlitejdbc currently has > no choice but to throw an exception).
This is not a bad idea, and definitely worth exploring. However, I don't have the time right now. There would be some edge cases where unexpectedly large amounts of memory gets used. E.g., someone begins a very large query, but usually close()s it after reading about 10 tuples. During the read, executeUpdate() is hit, then suddenly a gigabyte of memory is being used. If the update came from another thread, it would be a race-like condition. But there's no helping people who do not take the time to understand SQLite. It is not a DBMS. That's why implementing this will be low priority for me, it's only a crutch for people who expect SQLite to behave like MySQL. The JDBC spec never promises that you can read and write concurrently, people just take it for granted. d. --~--~---------~--~----~------------~-------~--~----~ Mailing List: http://groups.google.com/group/sqlitejdbc?hl=en To unsubscribe, send email to [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
