[sqlite] Auto Reply: Re: Memory leak in sqlite 3.7.0

[greg . burd]

I will be out of the office starting July 26th on medical leave and generally 
unreachable. For all issues please contact my manager, Dave Segleau 
, for help during this time.

apologies I hope to be back soon,

-greg
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Auto Reply: Auto Reply: using sqlitejdbc-v056 with ant build file

[greg . burd]

I will be out of the office starting July 26th on medical leave and generally 
unreachable. For all issues please contact my manager, Dave Segleau 
, for help during this time.

apologies I hope to be back soon,

-greg
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Auto Reply: using sqlitejdbc-v056 with ant build file

[greg . burd]

I will be out of the office starting July 26th on medical leave and generally 
unreachable. For all issues please contact my manager, Dave Segleau 
, for help during this time.

apologies I hope to be back soon,

-greg
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Multithreading support approach

[Greg Burd]

I think this will change with SQLite 3.7's new Write Ahead Logging (WAL) 
feature.  Over in the Berkeley DB team we have put a btree that implements 
transactional storage based on WAL under the SQLite parser/processor.  This 
technique can support a different locking model and lead to a very high degree 
of concurrency resulting in good scalability.  You can try out our version or 
wait for SQLite 3.7 and see if it does something similar.

http://download.oracle.com/berkeley-db/db-5.0.26.tar.gz  :)


-greg

@gregburd and @berkeleydb on Twitter, Product Manager for Berkeley DB at Oracle 
(so I'm a tad biased...)

> -Original Message-
> From: Simon Slavin [mailto:slav...@bigfraud.org]
> Sent: Friday, July 02, 2010 1:46 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Multithreading support approach
> 
> 
> On 2 Jul 2010, at 6:14pm, Cargnelutti, Pablo Fernando wrote:
> 
> > Sqlite implements table level lock?
> 
> No.  SQLite locks the entire database file with all tables and views in
> it.
> 
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Accessing an sqlite db from two different programs

[Greg Burd]

Ian,

You might try Berkeley DB 11gR2 (read: Berkeley DB and SQLite combined) it 
allows you to run multi-process access to a SQLite database and scales really 
well.

http://download.oracle.com/berkeley-db/db-5.0.21.tar.gz

Give it a whirl and then let me know what you think.

-greg

> -Original Message-
> From: Ian Hardingham [mailto:i...@mode7games.com]
> Sent: Tuesday, June 22, 2010 12:44 PM
> To: General Discussion of SQLite Database
> Subject: [sqlite] Accessing an sqlite db from two different programs
> 
> Hey guys,
> 
> If I have program 1 and program 2 which both open the same db file, but
> they never write to the same table (but might be reading one written by
> another), do I need to do a lot of locking?  I'm not worried about race
> conditions.
> 
> Thanks,
> Ian
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Oracle joins the SQLite Consortium

[Greg Burd]

Igor,

Happy to help.  :)  First IANAL and what I'm about to say is a GROSS 
simplification of intricate intellectual property law so with that in mind.  
The Sleepycat License basically says, "anything that includes/uses/calls-into 
Sleepycat Licensed software (in this case Berkeley DB) and is redistributed to 
a 3rd party must itself be software made available under and open source 
license (or be in the public domain)."  If you write a proprietary application 
and use the BDB libraries then before you redistribute it to a 3rd party you 
will need a license to do so.  That's the dual license in a nutshell, that's 
how we make money on BDB products.

Over time the minor differences identified by Roger Binns and others (Mike 
Owens for instance) will be smoothed out to be as close to SQLite-standard 
(bug-for-bug, feature-for-feature, behavior-for-behavior) identical except 
where we are trying to bring new value to SQLite.  The goal is for a SQLite 
programmer or program to switch to BDB SQL and find instant benefit in certain 
use cases.  This is like what happened to MySQL with its various storage 
engines.  Most of the time you just swapped out one for the other and had 
different storage features available but sometimes there was a bit more leg 
work to be done.

MySQL and SQLite serve different communities, we don't ever expect them to 
seriously overlap.  There is a lot of new storage, data, and processing power 
in applications on devices that don't do well running a client/server database 
with a DBA.  That's the market for BDB 11gR2 (read: BDB+SQLite).  That's how we 
draw the line, I hope it makes sense to you.

Oracle's mobile and embedded database of choice is Berkeley DB 11gR2 (read: 
BDB+SQLite).  We believe that it has the right balance of 
features/functionality for those environments.  The environments being a) in 
devices, b) in applications needing structured local storage, c) in other 
places where small+SQL is a win.  In all those cases we hope to bring benefit 
by allowing synchronization of data from SQLite or BDB 11gR2 (read: BDB+SQLite) 
databases back to Oracle Database datacenters.

SAP bought Sybase for their mobile platform which was a mistake when you 
consider that there is a better/equivalent/low-cost mobile database (which now 
has an enterprise app management and data sync server) out there that is far 
more popular and pervasive.  This is not an embrace/extend play, we're joining 
into a successful ecosystem and working to improve it in ways that enterprise 
customers require (which isn't always the primary focus of SQLite development, 
and for good reason).  We are a good friend and partner to open source project 
communities.  This is a strong and sensible mobile database strategy.

If you're not on the steamroller, you're part of the asphalt - right?

-greg 

> -Original Message-
> From: Igor Sereda [mailto:ser...@gmail.com]
> Sent: Wednesday, June 23, 2010 8:44 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Oracle joins the SQLite Consortium
> 
> 
> Greg,
> 
> Thanks for the explanation. So it's Sleepycat license, ok, but we still
> can't use it in an application with proprietary code, right?
> 
> It would be interesting to track the progress of SQLite/BDB. Roger
> Binns has
> noted some important issues, but granted those are solved, would you
> say
> SQLite/BDB is going to be an acceptable solution as an in-process
> server-side database?
> 
> Is there a vision how BDB, now with SQLite, fits into the family of
> Oracle's
> products? Clearly it's far from Oracle Database, but do you foresee
> competition with MySQL team? Just asking :)
> 
> Igor
> 
> 
> 
> Gregory Burd-2 wrote:
> >
> > Hello,
> >
> > My name is Greg, I'm one of the product managers within Oracle
> working on
> > the Berkeley DB products.  I joined Oracle when Sleepycat was
> acquired but
> > I've been working on BDB for nearly nine years now.  I was the one
> who
> > pushed hard to integrate SQLite and BDB, I think the two products go
> well
> > together without damaging either one.  I am also the guy responsible
> for
> > most of the messaging on the Oracle.com website (with a lot of
> editing
> > oversight and marketing input), so if you want to question something
> there
> > please just email me.
> >
> > We here in the Berkeley DB team within Oracle's Embedded Database
> group
> > are thrilled to have Oracle join the SQLite Consortium.  Today and in
> the
> > past our goal with open source collaborations has been to work
> closely
> > together, help each other out, keep things informal-yet-formal, and
> give
> > credit where credit is due.  The SQLite product is excellent, we
> don't
> > want or need to fork it.  The SQLite3 ANSI C API is like the BDB ANSI
> C
> > key/value API, de-facto standards in their respective spaces.  From
> our
> > view this combination is like chocolate and peanut butter, two great
> > products that go well together.  Some will like this combo and 

Re: [sqlite] Oracle joins the SQLite Consortium

[Greg Burd]

Hello,

My name is Greg, I'm one of the product managers within Oracle working on the 
Berkeley DB products.  I joined Oracle when Sleepycat was acquired but I've 
been working on BDB for nearly nine years now.  I was the one who pushed hard 
to integrate SQLite and BDB, I think the two products go well together without 
damaging either one.  I am also the guy responsible for most of the messaging 
on the Oracle.com website (with a lot of editing oversight and marketing 
input), so if you want to question something there please just email me.

We here in the Berkeley DB team within Oracle's Embedded Database group are 
thrilled to have Oracle join the SQLite Consortium.  Today and in the past our 
goal with open source collaborations has been to work closely together, help 
each other out, keep things informal-yet-formal, and give credit where credit 
is due.  The SQLite product is excellent, we don't want or need to fork it.  
The SQLite3 ANSI C API is like the BDB ANSI C key/value API, de-facto standards 
in their respective spaces.  From our view this combination is like chocolate 
and peanut butter, two great products that go well together.  Some will like 
this combo and find value in it, others won't.  That's okay, in fact it's the 
way it should be.  We are thrilled to be joining this community, we're not the 
enemy or the competition.

Clearly there are going to be many questions, I'm here to help answer them as 
best I can.


License: Oracle Berkeley DB is not licensed under the GPL.  Berkeley DB is 
released under the terms of the Sleepycat License.  The Sleepycat License is 
significantly different from the GPL, take a look.  
http://en.wikipedia.org/wiki/Sleepycat_License

Compatibility: "... [the] application-level behavior of the two products is 
identical..."  Okay, this is a bit of an overstatement at this point and I 
freely admit that.  This is our long-term goal, so I think it's fair to put 
have it on our site.  Basically we're telling people that we'd like to be as 
close to 100% drop-in compatible as possible while still providing the unique 
value of Berkeley DB as a btree storage engine.  For our first release, I think 
you'll have to admit that we are very close to the mark.  We're already nearing 
a patch release and it is even closer.  This will evolve, both SQLite and BDB's 
SQL will benefit along the way.

Comparison: "... improved performance, concurrency, scalability, and 
reliability."  Fundamentally, we are faster because we don't lock the entire 
database on writes as SQLite's btree does.  BDB is designed for concurrent 
multi-process/thread access, this gives us a speed advantage when there is any 
concurrency in the system.  Single-threaded performance is a more 
apples-to-apples comparison and this is more evenly matched.  The product is 
evolving fast, we're constantly finding ways to use advanced features in BDB 
for special cases in SQLite.  Again, we're only just in release 1 of the 
combined product and we're already in very good shape to be faster in general.

MVCC: We're going to add in support for MVCC (snapshot isolation), it's not 
there in the first release.  This will continue to help speed up concurrent 
access and prevent deadlocks.

HA: Clearly we're going to integrate (in a SQLite-friendly way) support for 
HA/replication.  It's not there in this release.  If you have ideas for how to 
properly make this fit into the product let us know!  Should it be a PRAGMA?  
Should it be C-functions?  Something else?  Speak up now.

Compaction: We punted on compaction in the first release because we wanted to 
do it using BDB's built-in compaction code (which can compact the database and 
optimize the btree while it's being used, it can even do this a little bit at a 
time so as not to be overly disruptive).  We didn't get this into the code line 
in time for the first release, it's coming very soon.

Compression: BDB has support for compression of things stored in the database, 
this is something we hope to integrate into the SQL API very soon.

Encryption: Again, we are hard at work on this.  BDB already supports encrypted 
databases, so it won't be hard to do.


We are also working on a comparison paper with Mike Owens (of "The Definitive 
Guide to SQLite" fame).  We hope to get this finished very soon and make it 
available for comment.  Mike is doing a great job of really providing a 
critical view of our combined product, which is exactly what we want.

There is a lot more we're working on, we're focused on a number of improvements 
in BDB itself and in our adaptor layer between BDB and SQLite.  What's great 
about this is that for fifteen years we had avoided SQL and just focused on 
being the best transactional storage engine around and I'd say we did a pretty 
good job of that.  Now we can happily join forces with a great community 
focused on the SQL piece.  SQLite does an amazing job of providing the features 
of a relational database and SQL92 in a