Ohloh by Black Duck

 Follow @ Meta   Join Now

 Settings |  Report Duplicate
Moderate Activity
46

News

  Analyzed 12 days ago based on code collected 12 days ago.
 
Secure client/server communication and pluggable sockets
Posted over 3 years ago by Adriano Verona
Due to community requests, we just introduced SSL support in C/S mode!
   
Using the new SSL support is really straightforward: just add SslSupport configuration items to client and server configurations and you are done! The .Net ... [More] and Java API are slightly divergent, due to differences in the platform support for SSL.

.Net Platform

In .Net, on the server side, ServerSslSupport constructor expects the certificate (a X509Certificate2 instance) to be used to authenticate the server.

At the client side, ClientSslSupport constructor expects a predicate which will be used to validate the server certificate. This predicate may use its parameters (the server's certificate, certificate chain and a SslPolicyErrors enumeration) to decide whether the authentication should succeed or fail.

This initial version does have room for improvements: it doesn't support mutual authentication and doesn't expose all available SSL options (such which protocol should be used, etc.)

Usage:

// Server Side
public void ConfigureServer(IServerConfiguration config)
{
config.AddConfigurationItem(new ServerSslSupport(ServerCertificate()));
}
// Client Side
private void ConfigureClient(IClientConfiguration config)
{
config.AddConfigurationItem(new ClientSslSupport(ValidateServerCertificate));
}
private static bool ValidateServerCertificate(
object sender,
X509Certificate certificate,
X509Chain chain,
SslPolicyErrors sslPolicyErrors)
{
return certificate.Subject.Contains("CN=whatever.example");
}   
For more details you can look into this test case.

Java Platform

On the Java side the certificates to be used are retrieved from the user's key store by default, however, you can supply a custom SSLContext for more fine grained control over the configuration. Mutual authentication is possible here out of the box as supported by the platform SSL API.

Usage:

// will retrieve certificate(s) from user's default keystore
config.add(new SSLSupport());

// custom ssl context
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(...);
config.add(new SSLSupport(context));

For more details you can look into this test case.

Keep in mind that SSL does impose a performance impact (since now we have extra round trips between client/server during the initial SSL "handshake", encryption, etc).

In order to support SSL we refactored our socket layer, introducing pluggable sockets. By implementing your own Socket4Factory (and associated Socket4 and ServerSocket4 interfaces), you can basically introduce any transport protocol you like. Potential candidates might be compressed socket streams or Unix domain sockets - we still have to experiment with the new freedom ourselves.

We are looking forward to hear your opinion.

Best

Yours db4o team [Less]
Release Notes 7.13 Development Release
Posted over 3 years ago by Tetyana Loskutova
A new development release 7.13 is online and here is the list of the Jira fixes that goes into it:

OMN-182 - Remove defragment functionality from OMN

OMN-179 - Include OMN in 7.4 Production and Stable downloadable db4o ... [More] distribution

OMJ-152 - Remove defragment functionality from OMJ

COR-1849 - Query against untyped value type fields fails with empty resultset

COR-1844 - [LINQ] Contains() constrains are not optimized on types other than IList

COR-1840 - Call IdSystem methods directly, without the detour through Transaction

COR-1837 - Investigate build failure in UnavailableGenericClassCollectionTestCase

COR-1836 - Move Ssl support to cs.optional project

COR-1834 - [.Net] Constrain is ignored for non indexed Guids

COR-1833 - Memory leak in C/S mode

COR-1832 - "Configuration of the Object class is not supported." exception as a result of using Identity()

COR-1830 - SSL support java C/S

COR-1828 - C/S queries return no objects if prefetchObjectCount is set to zero

COR-1827 - Create specialized int and long CircularBuffer and use it in Caches

COR-1826 - Factor ID system out of transaction

COR-1823 - Commit callbacks are missing objects in the deleted collection

COR-1820 - Review/remove unused .net solutions

COR-1818 - Create dropin replacement for Set/HashSet (Set4/HashSet4)

COR-1817 - Introduce dedicated configuration items for client/server/embedded configurations

COR-1815 - Resolve dependency from db4o.optional to db4o.cs

COR-1814 - Configuration reuse produces deadlock

COR-1813 - Inconsistency in the reference systems if the server ObjectContainer is accessed via networking and embedded clients

COR-1809 - Potential memory leak in ClientTransactionPool

COR-1808 - SetSemaphoreTestCase occasionally fails

COR-1806 - Removing from ReferenceSystem by ID does not check ObjectReference identity

COR-1805 - Query returns unrelated objects.

COR-1804 - Server keeps accumulating prefetched IDs

COR-1802 - Fix namespace in JavaSupport.cs for 'Db4objects.Db4o.Internal.CS.Messages'

COR-1800 - [.Net] Runtime.cs should throw for not supported methods (like Notify*()) on CF

COR-1798 - Classes in assembly that contains "db4o" in its names are storable but not retrieveable

COR-1796 - Db4objects.Db4o.Ext.ObjectNotStorableException while deploing to server (.Net)

COR-1795 - Renaming of generic collection throws NullReferenceException

COR-1779 - Introduce a way to register ClientConnectionsMBean

COR-1776 - Test deletion on older database version in the migration tests

COR-1747 - SSL support .net C/S

COR-1738 - .NET System.Collections.ObjectModel.Collection<> in nested class is not saved

COR-1691 - DateTimeOffset field in WHERE clause produces empty results

COR-1558 - db4o should throw when a configuration is reused

COR-1526 - TA + TP for Java Collections extending JDK classes

COR-606 - Pushed updates throws NullPointerException. [Less]
7.12 Production - Release Notes
Posted over 3 years ago by Tetyana Loskutova
Hi there!

There've been a lot of work put into the 7.12 version and we've decided that it is ready to be called a Production release. The previous 7.4 Production&Stable Release will be called Stable now and will be updated in the ... [More] download center with some important fixes in .NET reference system.

Here is the list of changes since the 7.12 Development Release:

COR-1849 - Query against untyped value type fields fails with empty resultset

COR-1844 - [LINQ] Contains() constrains are not optimized on types other than IList

COR-1837 - Investigate build failure in UnavailableGenericClassCollectionTestCase

COR-1836 - Move Ssl support to cs.optional project

COR-1834 - [.Net] Constrain is ignored for non indexed Guids

COR-1833 - Memory leak in C/S mode

COR-1832 - "Configuration of the Object class is not supported." exception as a result of using Identity()

COR-1830 - SSL support java C/S

COR-1828 - C/S queries return no objects if prefetchObjectCount is set to zero

COR-1827 - Create specialized int and long CircularBuffer and use it in Caches

COR-1823 - Commit callbacks are missing objects in the deleted collection

COR-1820 - Review/remove unused .net solutions

COR-1818 - Create dropin replacement for Set/HashSet (Set4/HashSet4)

COR-1817 - Introduce dedicated configuration items for client/server/embedded configurations

COR-1815 - Resolve dependency from db4o.optional to db4o.cs

COR-1809 - Potential memory leak in ClientTransactionPool

COR-1808 - SetSemaphoreTestCase occasionally fails

COR-1806 - Removing from ReferenceSystem by ID does not check ObjectReference identity

COR-1805 - Query returns unrelated objects.

COR-1804 - Server keeps accumulating prefetched IDs

COR-1802 - Fix namespace in JavaSupport.cs for 'Db4objects.Db4o.Internal.CS.Messages'

COR-1800 - [.Net] Runtime.cs should throw for not supported methods (like Notify*()) on CF

COR-1798 - Classes in assembly that contains "db4o" in its names are storable but not retrieveable

COR-1796 - Db4objects.Db4o.Ext.ObjectNotStorableException while deploing to server (.Net)

COR-1795 - Renaming of generic collection throws NullReferenceException

COR-1779 - Introduce a way to register ClientConnectionsMBean

COR-1776 - Test deletion on older database version in the migration tests

COR-1747 - SSL support .net C/S

COR-1738 - .NET System.Collections.ObjectModel.Collection<> in nested class is not saved

COR-1691 - DateTimeOffset field in WHERE clause produces empty results

COR-606 - Pushed updates throws NullPointerException. [Less]
db4o Maven snapshot repository available
Posted over 3 years ago by Carl Rosenberger
Responding to a frequent request from our community, we now supply Maven snapshots of both the stable and the trunk (continous) db4o builds.
The repository is available at the following URL:https://source.db4o.com/maven
The artifact layout ... [More] corresponds to the structure you find in our regular downloads. It has changed between versions 7.4 and 7.12: In 7.12 we factored out the optional and cs (Client/Server) modules to become separate jars and we supply a full (no dependency) jar that contains the full db4o distribution including all required and optional modules.
Don't shy away from working with our latest 7.12 trunk version. It only goes online after all regression tests have passed.
  [Less]
A Closer Look At Deep Prefetching
Posted over 3 years ago by Patrick Roemer
Tweaking the configuration options for any sufficiently complex library or application can often become indistinguishable from black magic for the "uninitiated". Turning the knob for one single setting, you usually can't expect linear changes in ... [More] runtime behavior - in most cases there's a variety of boundary conditions and side effects to be taken into account. To avoid random probing through an abundance of seemingly erratic changes in behavior, it's mandatory to know what internals are affected by the given configuration setting, and to monitor the effects of changes to this setting experimentally to verify expectations. In this post, we'd like to exercise this throughout a simple example involving two features that have recently been introduced to db4o: Deep Prefetching for C/S mode and runtime statistics. (Even if you don't use db4o in C/S mode, it may still be worthwhile to keep on reading, since some of the observations made apply to db4o configuration optimization in general - or actually even more, to performance tweaking in general.)

As a sample application, we're using a rather minimalist and artificial "task manager" application. A task simply consists of a name and a (potentially empty) collection of subtasks.

We recommend to download the full sample application project attached to this post and refer to the sources as you read along.

The application simply consists of a client requesting full task object graphs from a server hosting a pre-created database. To simplify matters even further, all root tasks in the database have the same size, i.e. they all represent complete n-ary trees of depth d, n and d being configurable for different runs.

The relevant application settings are:

NUM_ROOT_TASKS: The number of top level tasks in the database
NUM_SUBTASKS: The number of subtasks each task owns
TASK_DEPTH: The depth of a root task object graph
RESULT_SIZE: The number of root task graphs retrieved in a single query

We'll compare three different combinations of settings for the configuration options relevant for deep prefetching:

No prefetching at all (no_prefetch)
Prefetching the full graph for a single root task (single_prefetch)
Prefetching the full result set (full_prefetch)

Due to the artifical nature of our setup, we can give accurate numbers for each of these settings - in real world scenarios, this will have to be replaced by heuristic approximizations. Here are the configuration settings used:

 
prefetchDepth

prefetchObjectCount

prefetchCacheSize

no_prefetch

 0
 0
0

single_prefetch
 GRAPH_SIZE * 2

1

GRAPH_SIZE * 2

 full_prefetch
 GRAPH_SIZE * 2

RESULT_SIZE

RESULT_SIZE * GRAPH_SIZE * 2

GRAPH_SIZE is the total task count per root graph, i.e. (1 - NUM_SUBTASKS^TASK_DEPTH) / (1 - NUM_SUBTASKS). The number of objects as seen by db4o is twice this number, since there is one additional ArrayList per task to keep the subtasks.

For our scenario, we'll use the following application settings:

NUM_ROOT_TASKS = 500
NUM_SUBTASKS = 5
TASK_DEPTH = 5
RESULT_SIZE = 10
GRAPH_SIZE for these settings is 781, the total number of objects retrieved in a single query is 15620 accordingly.

Running the application in no_prefetching mode with timed readings yields the following results:

Prefetch depth: 0
Prefetch object count: 0
Prefetch cache size: 0
AVG QUERY TIME: 1805.30 ms
AVG ACTIVATION TIME: 9844.80 ms
TOTAL TIME: 582616 ms

We certainly do hope there's room for improvement here, so let's take a peek at client networking activity through our JMX runtime statistics:

We can see that there's a lot of message exchange going on between client and server. With no prefetching enabled, the client will request the data for each single object separately during activation.

Switching to full_prefetching, we get the following results:

Prefetch depth: 10
Prefetch object count: 10
Prefetch cache size: 15620
AVG QUERY TIME: 5204.46 ms
AVG ACTIVATION TIME: 1011.90 ms
TOTAL TIME: 310848 ms

Let's take a look at the networking statistics for this scenario:

With this setup, the complete query result (15620 objects) is transferred to the client in one single message. Accordingly, we see a significant drop in the number of messages sent by the client: Instead of a continuous stream of single object data requests, we are now left with the query request messages exclusively. Note that query execution time takes significantly longer than in the no_prefetching setup, since the actual network transfer now is measured as part of this reading. Activation is much faster, because it's now happening completely on the client, using the client-side slot cache, without any intermediate message exchange.

Nevertheless, there doesn't seem to be a steady flow of incoming bytes. Instead we find a sequence of high activity peaks followed by idling periods. We suspect an overhead incurred by the huge network packet size as well as for client-side cache maintenance. Let's try the middle ground and reduce prefetching to what's needed to transfer a single root task graph each time ObjectSet#next() is called:

Prefetch depth: 10
Prefetch object count: 1
Prefetch cache size: 1562
AVG QUERY TIME: 1795.88 ms
AVG ACTIVATION TIME: 539.92 ms
TOTAL TIME: 116819 ms

Cool, this setup gave us the best results. We have improved 5x over the no_prefetching setup, and almost 2x over the full_prefetching. For completeness, let's take a peek at network activity for this scenario:

We find slightly increased message exchange (because now we get one request per result set element graph) and a much more steady flow of incoming bytes.

Some thoughts to take away from this experiment:

The best prefetching settings highly depend on your object model and the characteristics of your queries. A good rule of thumb is to provide enough cache to accommodate for a single result set entry subgraph.
Try to approximate the "sweet spot" incrementally and verify your assumptions by monitoring the changes in behavior.
Results may differ depending on network quality - the figures we present here have been gathered from an intranet setup. The slower your network is, the more impact you may gain from reduced message exchange. [Less]
New 7.4 stable release with ObjectManager Enterprise
Posted over 3 years ago by Carl Rosenberger
Today we have put a maintenance release of our stable 7.4 version online.
Here are the three most important changes that we made by porting back code from our development release:(1) We now distribute ObjectManager Enterprise (OME) along ... [More] with our stable distribution also. If you are a 7.4user you can now use this tool to browse and modify database files. OME comes as an Eclipse plugin forJava and as a Visual Studio plugin for .NET. OME needs to be installed separately from:- /db4o-7.4/ome (Java)- /db4o-7.4/omn2008 (.NET: Visual Studio 2008)- /db4o-7.4/omn2005 (.NET: Visual Studio 2005)
(2) A Configuration object can no longer be reused to open multiple ObjectContainers. Please always call Db4o.newConfiguration() (Java) / Db4oFactory.NewConfiguration() (.NET) to create a new Configuration object for each ObjectContainer / ObjectServer that you want to open. This change was necessary because we became aware that shared configuration state could lead to unwanted locking issues. Reusing a Configuration for a second open call will now throw an exception. We recommend only to use the openFile()/openServer() calls that require a Configuration object as one of the parameters. This way you can make sure that you are explicit about which Configuration you use.
(3) In Client/Server mode each client now maintains it's own ReferenceSystem on the server side, should there be the need to activate objects to execute unoptimized queries. This way we can guarantee better isolation by executing queries against uncommitted state.
Here is a list of important Jira issues that have been marked as fixed for the 7.4 branch since the previous 7.4 release:COR-1814 - Configuration reuse produces deadlockCOR-1813 - Inconsistency in the reference systems if the server ObjectContainer is accessed via networking and embedded clientsCOR-1806 - Removing from ReferenceSystem by ID does not check ObjectReference identityCOR-1725 - BLOAT cache fills up the heapCOR-1597 - db4o_osgi with rcp app problemCOR-1596 - Allow to specify dedicated target storage for backupCOR-1582 - Activating a map to depth 1 prevents it from being activated to depth 2COR-1558 - db4o should throw when a configuration is reusedCOR-1809 - Potential memory leak in ClientTransactionPoolCOR-1598 - Diagnostics warns about missing field indexes on class-only queriesCOR-1599 - Synchronize KnownClassesRepository access in GenericReflector against database lock
Enjoy the new release!Your db4o team.  [Less]
Release Notes - 7.12 Development Release
Posted over 3 years ago by Tetyana Loskutova
Hi!
A new db4o version is out - 7.12 Development.

Here is what is in it:

OMN-178 - Reviewing OMN code. Changes made in code so that OMN works for java db

OMJ-149 - Include OMJ in 7.4 Production and Stable downloadable ... [More] db4o distribution

COR-1793 - BlockingQueue may throw BlockingQueueStoppedException in case of spurious wakeups

COR-1789 - Introduce PerformanceCounters/JMX statistics for activation/deactivation, objects stored/deleted

COR-1787 - [.Net] Make sure PerformanceCounters instance are removed at ObjectContainer.Close()

COR-1781 - Blog about Silverlight assembly loading issue fixed

COR-1780 - Blog about Guid typehandler

COR-1778 - Introduce optional, user-specified name/label for databases

COR-1775 - Separate sorting/ordering step from SODA processing

COR-1773 - Enable defragment before actual migration in format migration tests.

COR-1768 - Base class classmetadata should not be take into account while storing derived ones

COR-1765 - JMX/perfmon: WeakReferences and FreespaceManager

COR-1761 - LINQ-Ordering on multiple properties throws a Db4oException: Unexpected exception: this..size()=1, other.size()=0

COR-1760 - ArrayList4 Generic IEnumerableGetEnumerator() should be implicity declared and the IEnumerable.GetEnumerator() explicitly declared

COR-1759 - [LINQ] Calls to String.Contains() produce wrong results

COR-1755 - Refactor deep prefetching client slot cache to use Cache4

COR-1752 - [.Net] Expose performance counter instances for each container

COR-1749 - JMX/perfmon: Networking statistics

COR-1748 - Investigate system assembly not being resolved in OMN

COR-1730 - create proper bundles with OSGi headers

COR-1678 - [Silverlight] Profile application to spot bottlenecks

COR-1646 - File lock must be released after emergency shutdown

COR-1637 - Prepare Silverlight tests for running in CC build

COR-1519 - Typehandler for System.Guid

COR-1062 - Sort result incorrect after OR

COR-377 - InMemoryObjectContainer creates a lot of short lived byte[] [Less]
Watching over db4o's shoulders the .NET way
Posted over 3 years ago by Adriano Verona
Hi.
This post presents a .Net centric view of the newly introduced support for better runtime monitoring into db4o (as described in this post), so, before you continue reading please, go read the aforementioned post! I'll assume you've read it. ... [More]

Have you read it yet?

No? Go there, I'll wait for you.

Ok. let's continue...

As you may already know for now, in the last few weeks, we have been busy adding more sophisticated monitoring support to db4o in the form of "Runtime Statistics" a term that we coined because we needed a common way to refer to "these things" in a platform agnostic way (you know, Java developers would not be happy if we just used "Performance Counters" and .Net developers would not be happy either had we choose MBean :); in this post I'm going to use the more natural name in the platform: Performance Counters. If, for some reason, you are not familiar with this concept or want to refresh your knowledge on the subject we recommend to read the MSDN documentation here and here and also this article on codeproject.

After reading the companion post you should already have a good idea about what monitoring data db4o allows you to collect and how it can be useful but we intentionally omitted a description of how to configure and consume this information which is the goal of this post.

The first step to be able consume monitoring information is to let windows know about the counters which means that you either run Db4oTool with the install-performance-counters command line parameter or call the method Db4oPerformanceCounters.Install() from your code. Note that this step is required only once per machine running db4o and also that it requires administrative rights so you probably will perform it at application install time (as opposed to runtime).

With the counters in place, the next step is to configure db4o to start collecting the data. As we explained in the companion post, the process of collecting such information does pose some overhead so we adopted an opt in model grouping counters in the following categories (each category in bold configures db4o to collect statistics for the respective set of counters):

Queries

General

Native Queries / LINQ

FreeSpaceManager

Reference System

IO

Networking (x Connected Clients)

In order to select the category/categories you are interested in, add an instance of the respective xxxxxMonitoringSupport() class to db4o configuration as in the following sample:

IEmbeddedConfiguration config = Db4oEmbedded.NewConfiguration();

// Query
config.Common.Add(new QueryMonitoringSupport());
config.Common.Add(new NativeQueryMonitoringSupport());

// Networking
config.Common.Add(new NetworkingMonitoringSupport()); 

// IO
config.Common.Add(new IOMonitoringSupport());

// Reference System:
config.Common.Add(new ReferenceSystemMonitoringSupport());

// FreeSpaceManager
config.Common.Add(new FreespaceMonitoringSupport());

 

Thats it!

Once configured no other action is required to start collecting the information (other than exercising the pieces of code that triggers the interesting counters :)

Next step is to consume the information being collected which can be done either through PerfMon (the main tool in Windows designed to view such counters) or programmatically. We are going to show you how to see the counters using PerfMon first, so start PerfMon.exe and you should see its main window (since I'm running Windows 7, your actual PerfMon window may look a little bit different than mine).

Next step, press + button in the toolbar to select which counters you want to monitor;

 In the window that shows up (in Available Counters) locate and expand Db4o and then select the desired counters. Next, select the instances you want to monitor.

 Each opened db4o database (or client) will be represented as an instance in the list "Instances of selected object". Local and server databases will display the database file name (in the sample above mydb.db4o) and clients (in C/S mode) will be shown as local port => server ip:port). You may monitor as many instances as you want simultaneously.

That's it again ;)

Now that you already know how to monitor db4o performance counters it is time to learn how to consume them programmatically since this can be useful in some scenarios. Accessing db4o performance counters programmatically is just a matter of calling the Db4objects.Db4o.Monitoring.Db4oPerformanceCounters.CounterFor() method passing the counter and the object container you want to monitor as in the following sample:

         PerformanceCounter bytesReadPerSec;
         bytesReadPerSec = Db4oPerformanceCounters.CounterFor(PerformanceCounterSpec.QueriesPerSec, db);

Now you can query PerformanceCounter's reference for any of it's properties / methods.

Have fun (and let us know what you think could be improved in this subject!)

Db4o Team! [Less]
Watching over db4o's shoulders the Java way
Posted over 3 years ago by Carl Rosenberger
As described in this posting, db4o 7.12 comes with new monitoring support to collect runtime statistics about performance relevant behaviour and state.
On the Java platform, statistics are published through Java Management Extensions (JMX). A ... [More] variety of JMX clients is available. Many of them are linked from here.
In this posting we will describe how to use the rather basic jconsole tool that comes with the Java JDK.
For the purpose of providing sample readings we have written a simple program that exercises various db4o tasks in a long running process.
It can be found in the 7.12 download in/src/db4oj.tests/src/com/db4o/db4ounit/optional/monitoring/samples/MonitoringDemo.java
You also need /src/db4oj.tests/src/com/db4o/db4ounit/optional/monitoring/samples/AllMonitoringSupport.javathat bulk registers all the available monitoring ConfigurationItems.
To view the generated statistics, run the MonitoringDemo application, then start jconsole from the command line.
A general tutorial on how to use jconsole is provided here.
First you need to connect to the MonitoringDemo process. Then you will find the db4o related readings on the "MBeans" tab. In the treeview on the left, you will see "com.db4o.monitoring".
Below this tree node you will find all open ObjectContainers that have JMX monitoring enabled. For each of them the respective runtime statistics categories will be listed. If you select the "Attributes" node for any of them, the corresponding set of attribute values will be shown along with their most recent reading.
By doubleclicking on the number value a graph will be displayed. (Admittedly not a very intuitive user interface, but that's jconsole.)
Here is a screenshot how results for IO readings could look like:

For some "exceptional" events, we also provide the option to subscribe to notifications.
In the categories where the "Notifications" node is visible, you can select it and click "Subscribe" on the bottom right. For example we provide notifications about unoptimized native queries and about class index scans.
If you consider looking into other tools than jconsole to monitor JMX statistics, we recommend to take a look at jManage. Here is a sample screenshot of how jManage nicely allows to combine multiple readings into one graph:

If you want to test whether your mail client gracefully handles full mailboxes: jManage also allows to send an email for every JMX notification received.
Enjoy the new functionality!
Your db4o team. [Less]
db4o runtime statistics
Posted over 3 years ago by Adriano Verona
Once a project hits production status and gets deployed it is in the wild (at least from the point of view of the development team) and it requires constant monitoring from IT. The more important the process, the more  important becomes the ... [More] ability to monitor the application behavior so IT members can take proactive actions and avoid potential problems.

Also, monitoring support can be a life/time saver during development, allowing developers to spot performance issues, wrong assumptions and the like before the application reaches the magical production status. Traditional  enterprise applications (such RDBMS, application servers, EJB containers, etc) has been delivering such monitoring capabilities either through well established platform mechanisms (MBeans, Performance Counters) or custom approaches.

While db4o provides API hooks to add custom logging for performance relevant figures, until now there's been no out-of-the-box way to have an ad hoc look under the hood before getting into real coding, or a convenient, standardized mechanism to monitor and display these values for a long-running process over a period of time.

We are proud to announce that starting with version 7.12 various "Runtime Statistics" will be exposed by db4o; we do believe that such statistics can provide useful information for developers and/or IT administrators who can consume this information either through the platform infrastructure (you can learn more details about .Net and Java specifics) or an API.

As of version 7.12 the following statistics will be made available (for more details about these statistics please visit db4o documentation center):

Queries

# class scans / sec
A class scan means that db4o will need to read each object of a given class in order to figure out whether the object should be included in the
result set of a query. In this case indexing the parent referencing field would avoid this costly operation and improve query times.

# queries / sec
Number of SODA queries executed per second.

Average query execution time
The time to retrieve the list of ids for the matching objects (this doesn't take the time to activate the objects into account)

# unoptimized native queries / sec
Number of native queries (per second) that were not optimized. Developers should strive to run only optimized native queries in order to
get the best possible performance.

# native queries / sec
Total number of native queries (either optimized or not) executed per second.

FreeSpaceManager

average slot size
The average size of free storage slots available.
Smaller slots are less likely to be reused.

# free slots
A high number of free slots indicates a high level of fragmentation.

# reused slots / sec
Number of reused free slots per second.

# bytes in free space management
A high value (with a high value of #free slots) is a good indication that defragmenting the database may bring performance improvements.  

Reference System

# objects in reference system
Total number of objects in the db4o reference system.

IO

# bytes read / sec
# bytes written / sec
# reads / sec
# writes / sec
# syncs / sec

Networking

Bytes Sent/Received
Bytes sent/received from/to clients.

Connected Clients
Number of currently connected clients.

Messages sent
Number of messages sent from/to db4o clients and servers. Developers can use this statistic as an indicator whenever their object models are
driving db4o to exchange too many messages between clients / server. This statistic is also useful to help developers to tweak
prefetchDepth / prefetchObjectCount configuration in order to minimize messages exchange between client / servers.  

.Net Specific (For more details about .Net specifics follow the link in the end of this post)
Note that since gathering these statistics does introduce some performance overhead (for most of then this overhead is so small that it is immeasurable) each set of runtime statistics (Queries, FreeSpaceManager, ReferenceSystem, etc.) must be configured independently (so you can decide which ones you want to track and pay the performance hit only for that ones).

One selects the category(ies) he is interested in publishing statistics for by adding an object of the respective xxxxxMonitoringSupport() class to db4o configuration as in the following sample:

IEmbeddedConfiguration config = Db4oEmbedded.NewConfiguration();

// Query
config.Common.Add(new QueryMonitoringSupport());
config.Common.Add(new NativeQueryMonitoringSupport());

// Networking
config.Common.Add(new NetworkingMonitoringSupport()); 

// IO
config.Common.Add(new IOMonitoringSupport());

// Reference System:
config.Common.Add(new ReferenceSystemMonitoringSupport());

// FreeSpaceManager
config.Common.Add(new FreespaceMonitoringSupport());

Last, but not least, these statistics are per object container (database file) so you can monitor as many open databases as you want.

If you can't wait for this functionality we invite you to go and download db4o continuous build version and give it a try, but please remember that it's a work in progress for while, so you may expect to see changes in the API and / or list of actual statistics supported.

For more details on how to consume these statistics, samples and more details, please, read the following blog posts:

For .Net see Watching over db4o's shoulders the .Net way.
For Java see Watching over db4o's shoulders the Java way.

Have fun! (and provide feedback ;)

Db4o team! [Less]
 

 
 

Project Summary

Code Data

SCM Data

Community Data

 

Creative Commons License Copyright © 2013 Black Duck Software, Inc. and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a Creative Commons Attribution 3.0 Unported License . Ohloh ® and the Ohloh logo are trademarks of Black Duck Software, Inc. in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.