db4objects Inc. has announced the availability of an object-oriented replication system that allows bi-directional object synchronization between relational persistence systems and object persistence systems.

The db4o Replication System (dRS) includes replication providers for the Hibernate object-relational mapper and for the db4o object database.

The functionality of the system in a nutshell:

• The system generates Unique Universal Identifiers (UUIDs) and version numbers for all stored objects.
• Since each stored object has a unique identity, objects can be replicated in multiple steps over multiple disconnected or partially connected persistence systems.
• Version numbers allow querying for and replicating changed objects only.
• The system automatically traverses changed members of replicated objects and replicates these changed members as well.
• Conflicts (objects changed in both peers of a replication session) can be resolved using object-oriented conflict handlers and business rules of persistent classes.

Further information can be found on the dRS product sheet. dRS is available for download under the GPL from the db4objects website.

I am not sure what this can do for me. I'v been trying to build a system with wich people can work on local servers. Those local servers synq themselves with the main server. When the main server is down the local servers can keep doing their work. When the main server is up again the local servers will have to get in synq again. As i said i'v been trying to do this but failed. Can db4objects be helpfull in this scenario?

I am not sure what this can do for me. I'v been trying to build a system with wich people can work on local servers. Those local servers synq themselves with the main server. When the main server is down the local servers can keep doing their work. When the main server is up again the local servers will have to get in synq again. As i said i'v been trying to do this but failed. Can db4objects be helpfull in this scenario?

Yes. In fact we do have quite a few customers that use db4o exactly for this purpose. We do offer professional support if you want to have such a system up and running fast.

I am not sure what this can do for me. I'v been trying to build a system with wich people can work on local servers. Those local servers synq themselves with the main server. When the main server is down the local servers can keep doing their work. When the main server is up again the local servers will have to get in synq again. As i said i'v been trying to do this but failed. Can db4objects be helpfull in this scenario?

Yes. In fact we do have quite a few customers that use db4o exactly for this purpose. We do offer professional support if you want to have such a system up and running fast.

My current customer propbably needs it in the neer future and I am not that crazy that I am going to build it myself, it is actually the one thing that scares me. Could you indicate what it would cost to have it set up.

neer future

near future that is ;-)

My current customer propbably needs it in the near future and I am not that crazy that I am going to build it myself, it is actually the one thing that scares me. Could you indicate what it would cost to have it set up.

How about talking to us directly?
http://www.db4o.com/commercial/purchase/enquiry.aspx
http://www.db4o.com/about/company/contact/

How about talking to us directly?

just did ;-)

I am not sure what this can do for me. I'v been trying to build a system with wich people can work on local servers. Those local servers synq themselves with the main server. When the main server is down the local servers can keep doing their work. When the main server is up again the local servers will have to get in synq again. As i said i'v been trying to do this but failed. Can db4objects be helpfull in this scenario?

Dennis, we're building a similar system with the plain Hibernate3 session.replicate() feature. We're quite early with development but our initial proof of concept tests are pretty successful. Can you briefly sum up what pitfalls you encountered? I think it'd be useful to know about your experiences.

Also, (from the db4o guys), a brief feature comparison of db4o and hibernate's built-in replication features would come handy with our current mission (we'd happily consider getting commercial support if applying db4o is a worthy and rewarding decision.

I am not sure what this can do for me. I'v been trying to build a system with wich people can work on local servers. Those local servers synq themselves with the main server. When the main server is down the local servers can keep doing their work. When the main server is up again the local servers will have to get in synq again. As i said i'v been trying to do this but failed. Can db4objects be helpfull in this scenario?

Dennis, we're building a similar system with the plain Hibernate3 session.replicate() feature. We're quite early with development but our initial proof of concept tests are pretty successful. Can you briefly sum up what pitfalls you encountered? I think it'd be useful to know about your experiences. Also, (from the db4o guys), a brief feature comparison of db4o and hibernate's built-in replication features would come handy with our current mission (we'd happily consider getting commercial support if applying db4o is a worthy and rewarding decision.

My approach was a transfer table in wich every update was stored. The transfer table records had a tablename field , a recordid field and an operation type field. An operation can be an add to a collection or a detachment of a reference and some more types.

Straight after the insert in the transfer table the record was send transient to the server whereafter the server can perform the update operation on the appropriate object.

My problem was the id thing. If the servers have to communicate asynq there is no way that the local server can issue valid id's without complex administration by means of number sequences or something like that.

The updates from one local server to the main server have to be further distributed to all local clients to have the system as a whole in synq.

In case of insert the local server that initially did send the insert to the main server will get back his own insert with another id because only the main server can issue valid id's, all references to the old id have to be updated in the local system whereafter the original local insert can be deleted.

If the main server is down the local system just keeps writing everything to the transfer table. A thread checks every now and then if the main server is up again and if it is up it sends all records in the transfer table to main server.

It kind of works but the transaction handling is really complicated and I dont know how it will behave in serious applications. It is also a time consuming feature to implement, it takes a lot of time wich i hardly have on my current project.

What exactly does the hibernate session.replicate() method do. How do you use it. What if the connection is lost?

We are using a different approach here. The basic idea is implementing a custom marker interface (eg. ReplicatedEntity) and adding timestamp-based versioning to all root-level hibernate entities needed to get replicated. Then a polymorphic HQL select is able to load all the changed entities (regardless their types) since the last replication with all related persistent objects, and session.replicate() can easily persist these object graphs into the target database while even watching for their correct version.

As for the key generation strategy, we used composite keys everywhere composed of a local sequencer id and the database instance id, therefore no collisions can happen upon data replication from different sources. We needed a custom IdentifierGenerator for this but it was no big deal to implement it.

Your approach is very similar to what we we are doing, Kristof.

Instead of using a timestamp-version number we use a simple counter. In order to be able to identify which changes occured since the last time two databases were syncronized, we store a "ReplicationRecord" object that memorizes when they were last in sync and we also syncronize the version counter to continue with the higher value of the two database session involved.

We tried to minimize ressource consumption for the UUID that we generate: It consists of a reference to a database identity object that we generate and a unique Java long per database.

The above systematic evolved from what we already have been doing quite a while for db4o replication. To get things to work with Hibernate, we add three fields to every table: version, UUID long part, UUID signature reference. Version numbers are updated by using a PostUpdateEventListener.

We could not use the Hibernate replicate() method, since the system also has to work with db4o.

Since you asked for the rewarding part to use db4o: db4o is considerably faster than any Hibernate/SQL combination, especially on ressource-constrained clients. Deployment also is easier. Add db4o.jar, issue one #open() call and your database is up and running. Refactorings also are better to handle.

We are using a different approach here. The basic idea is implementing a custom marker interface (eg. ReplicatedEntity) and adding timestamp-based versioning to all root-level hibernate entities needed to get replicated. Then a polymorphic HQL select is able to load all the changed entities (regardless their types) since the last replication with all related persistent objects, and session.replicate() can easily persist these object graphs into the target database while even watching for their correct version. As for the key generation strategy, we used composite keys everywhere composed of a local sequencer id and the database instance id, therefore no collisions can happen upon data replication from different sources. We needed a custom IdentifierGenerator for this but it was no big deal to implement it.

Sounds like a good approach. How do you handle the situation where the local server made some asynq changes that the main server does not accept. How do you roll that back locally, i guess some kind of history mechanism is needed to restore the old values.

Does db4o support transactions? Can you point me to an example of how you demarcate transactions in db4o? Also, if it does support transactions, what isolation level does it support? And does using the new replication system affect concurrency control and the isolation level?

Guglielmo

Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

.. or the World's First Pure-Java Terminal Driver

Why not use Sequoia?
https://forge.continuent.org/projects/sequoia

As opposed to what?

As opposed to what?

Whoops. Sorry. I thought it was the other thread ;-)

Guglielmo

Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

Does db4o support transactions?

Yes.

Can you point me to an example of how you demarcate transactions in db4o?

Work against db4o is always transactional. #commit() and #rollback() start new transactions immediately.

Also, if it does support transactions, what isolation level does it support?

Read committed.

And does using the new replication system affect concurrency control and the isolation level?

The new replication system is an external client to db4o and behaves like any other client.

And does using the new replication system affect concurrency control and the isolation level?

The new replication system is an external client to db4o and behaves like any other client.
In other words it does not support transactions.

Guglielmo

The new replication system is an external client to db4o and behaves like any other client.

In other words it does not support transactions

No. In other words it works with a single read committed transaction.

The new replication system is an external client to db4o and behaves like any other client.

In other words it does not support transactions

No. In other words it works with a single read committed transaction.

I was referring to the distributed one.