"it's electric" a plugin for The Energy Detective is using JE.

Here's a great blog entry about how to use JE from JSP pages.

The whitepaper that I wrote about BDB JE on Android is now available on OTN.

Thanks to Chris Eastland at Nebula Software Systems for the screen shot of this cool Google Maps/Android app built on BDB JE. The location data is stored in a JE database running on the device.

Finally(!) we can talk about the Sun acquisition. From the point of view of the Berkeley DB Java Edition group, this is really good news. For the past several years we've had a good relationship with many groups at Sun, but there was always the little issue of being in two different companies standing between us. The acquisition means that we can now work closer with those groups as well as new groups without worry about disclosing intellectual property on either side of the table. The level of collaboration between us should improve significantly.

Props to Chris Eastland of Nebulasoftwaresystems.com for putting together a Google Mapping app backed by JE. Each of the points on the screen are stored in a JE database on Android. The screen shot is from a Moto Droid.

image.bmp

While debugging a failing JE unit test issue on Android, I ran into an interesting bug with the Harmony implementation of IdentityHashMap on Dalvik (the Android runtime).

More than one person on the Berkeley DB team visits Reddit daily so it's nice to see that part of what makes Reddit work is our product. MemcacheDB (built on Berkeley DB using it's high availability (HA) feature to replicate cached data between nodes) is a natural fit for your permacache (key/value cache as a database of record) and it seems like it's working fairly well.

 Berkeley DB

 Charles Lamb's Blog

In his blog, Jeff Alexander of Sun's project Aura describes how they've standardized on a calling convention for JE which provides uniform, yet flexible, transaction and exception handling.

To read the entire article at its source, please refer to Berkeley DB Java Edition: Handling Transactions in JE 4.0

In his blog, Jeff Alexander of Sun's project Aura describes how they've standardized on a calling convention for JE which provides uniform, yet flexible, transaction and exception handling.

It's official: Berkeley DB Java Edition 4.0 was released today.

This release has High Availability and Replication (HA), improved IO performance (especially on Linux/ext3), and a jconsole plugin which should make performance tuning quite a bit easier for JE users.

To read the entire article at its source, please refer to Berkeley DB Java Edition 4.0 Released

It's official: Berkeley DB Java Edition 4.0 was released today.

This release has High Availability and Replication (HA), improved IO performance (especially on Linux/ext3), and a jconsole plugin which should make performance tuning quite a bit easier for JE users.

In a previous post I raised the topic of IO problems on Windows 7 (fsync was resulting in "Incorrect Function" IOExceptions). This again showed up more recently in this OTN thread. Fortunately, the reporting user supplied us with a reproducible test case which allowed us to characterize the problem.

A customer sent us a simple program and an environment with data. The program opened the environment (approx. 2GB) and scaned the records of one of the databases in primary key order. The records had been inserted in random (i.e. non-key-sequential order) order and this caused lots of random IO during the scan. The customer wanted to know how to make the scan go faster. We suggested using Database.preload() since that would sort the LSNs of all of the records in the database and then load the cache by reading the records in LSN order rather than key order.

I've just finished checking that JE 4.0 works properly on Android 1.6 (it does). But even better is that we'll be shipping a je-android.jar file with 4.0 when it's available ("by the end of CY2009"). This means that JE/Android users will no longer need to copy the JE sources into a project directory in order to modify the sources to replace references to javax.transaction.xa.* with references to stub classes. Instead, they will just need to copy the je-android.jar file into their project libs directory and they'll be ready for action.

For those in the Boston area:

The Boston "Big Data Summit" will be holding its first meeting on Thursday, October 22nd 2009 at 6pm at the Emerging Enterprise Center at Foley Hoag in Waltham, MA.

The Boston area is home to a large number of companies involved in the collection, storage, analysis, data integration, data quality, master data management, and archival of "Big Data". If you are involved in any of these, then the meeting of the Boston "Big Data Summit" is something you should plan to attend. Save the date!

Where to find Berkeley DB people & sessions at Oracle Open World

If you are interested in hearing about Berkeley DB, learning more about how the Berkeley DB products can be integrated into your applications/appliances/devices, seeing exciting Berkeley DB customer use cases or speaking directly with one of the Berkeley DB product development engineers, you can find us here:

Here are all of the Berkeley DB presentations at Oracle Open World. I've highlighted the presentation that my colleague Sam Haradhvala will be giving on Berkeley DB Java Edition High Availability.

----------------------------------------------------------------------
Where to find Berkeley DB people & sessions at Oracle Open World
----------------------------------------------------------------------

In a previous blog entry I wrote that JE worked on Android but that the DPL didn't work because of a lack of support for various methods (e.g. Class.getAnnotations()) in the Dalvik JVM.

I have verified that the Android 1.5 (and presumably recently released 1.6) SDK supports JE and DPL. JE/DPL on Android adds a major chunk of infrastructure to the Android platform in that a pure Java transactional POJO datastore is now available.

Three of us were working on a customer crisis late last night. The customer had a running environment which had some sort of transient state "issues". We were able to debug this live because they had the foresight to incorporate BeanShell into their system. This allowed us to look at lots of state and get a pretty good idea of what was going on. I strongly recommend taking a look at this library for use as a debugging tool, especially for deployed systems.

My colleague Tao Zhang has been working on a jconsole plugin which will let you monitor Berkeley DB Java Edition stats in real time. This will be especially useful for helping our customers debug performance issues. We're all really excited about this new feature which will be available in JE 4.0 (the corporate lawyers will only let me say "GA in CY 10"). I want to share some screen shots of this.

Here's a picture of the plugin.

Here is the press release for the latest BDB ("core") and BDB XML releases.

eWeek also has an article about this.

Today is a big day for Berkeley DB products. Not only are we releasing a new version of Berkeley DB, but we also are announcing the availability of a new version of Berkeley DB XML. This release makes use of the new features in Berkeley DB 4.8 and has many exciting features of its own.

New in Berkeley DB XML 2.5:

Today we are very happy to announce the availability of an amazing new version of Berkeley DB. This release is full of new features, performance improvements, and much more.

New in Berkeley DB 4.8:

A user has seen an IOException("Incorrect function") while performing an fsync in Windows 7 (as yet, unreleased) using JE 3.3.x. We have good reason to believe that this is a bug, or at least a change in behavior, in Windows 7's IO as the same program does not exhibit this behavior under Windows XP. In fact, we have never seen this exception ("Incorrect function") before.

We know of a workaround for the bug which we can give you if you run into this under Windows 7.

I've added a new entry to the BDB JE FAQ regarding JVM parameters for large cache sizes.

Here's the text of it:

What JVM parameters should I consider when tuning an application with a large cache size?

To read the entire article at its source, please refer to Berkeley DB Java Edition FAQ Entry on GC Params for Large Caches

Pierre Lindenbaum, we hear you. Thanks for taking Berkeley DB XML for a spin and writing up your experiences with the product!

I've added a new entry to the BDB JE FAQ regarding JVM parameters for large cache sizes.

Here's the text of it:

What JVM parameters should I consider when tuning an application with a large cache size?