[Logo] Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
[Expert]
Recoverability with DSO (but no database)  XML
Forum Index -> Terracotta Platform
Author Message
jfcloutier

neo

Joined: 10/18/2006 13:40:13
Messages: 4
Offline

I am pursuing an architecture where all my "data objects" behave as simple, in-memory JavaBeans. I want to avoid database mapping and database query languages (be they SQL, SODA etc.)

Without compromising an "all JavaBeans all the time" approach, I also want scalability and recoverability. I get scalability with DSO without messing up my "pristine" JavaBeans. Wonderful stuff. But how can I get recoverability (data model is restored after all servers are shutdown are rebooted) without a database? Prevayler is one option (snapshot + command pattern + journaling + write sequencing). How would a Prevayler-type approach mix with DSO? Do you see options other than Prevayler?

BTW I see DSO as part of an exciting trend toward the radical simplification of Java development achieved by relegating the complexities of managing boundaries to the infrastructure i.e. by taking "boundary management" out of the application.

Another co-conspirator is the ZK, ECHO2 crowd. These products use AJAX transparently to erase the browser-server boundary ( all you do is write an event-driven, server-based application, the infrastructure does the rest). AOP also plays a huge role by erasing "concern boundaries" from application code; logging, security, eventing etc. logic can be taken out entirely of the application logic. We may finally be seeing our way out of the J2EE mess.

Back to my question, any ideas on how to eliminate the "database boundary" together with using DSO?

Thanks.
grose

journeyman

Joined: 08/04/2006 07:58:08
Messages: 17
Location: Terracotta, Inc.
Offline

Hi jfcloutier,

It sounds as though you would benefit from knowing about DSO's persistent mode feature. In persistent mode, the server permanently writes object state to disk.

As the reference version of the configuration file describes it, "'permanent-store' causes the DSO server to write data immediately and permanently to disk. Upon server restart, data will be restored, meaning data underneath roots in your program will be restored to the exact state it was in when the server shut down."

I believe this is exactly what you're looking for. I'll private message you my email address. However, feel free to post questions to the board as well, so others can benefit.

Regards,

Gordon


Gordon Rose
Sr. Systems Engineer
Terracotta, Inc.
tgautier

seraphim

Joined: 06/05/2006 12:19:26
Messages: 1781
Offline

jfcloutier,

I think Gordon already answered your question but I found it remarkable that you and I are thinking along exactly the same lines!

In fact, I just built an application to showcase building an app using these ideas, I thought you might be interested. Have a look at : http://javathink.blogspot.com/2006/10/build-ajax-soap-app-in-15-minutes-part.html

Regards,

Taylor
[WWW]
grose

journeyman

Joined: 08/04/2006 07:58:08
Messages: 17
Location: Terracotta, Inc.
Offline

Hi Jean-Francois,

Our future support for annotations fortunately refers to DSO-specific annotations. DSO should not (and has not in our testing) break or interfere with non-DSO annotations in the instrumented bytecode.

As far as using AspectJ, you should just have to just compile aspects as usual and add aspectjrt.jar to your application -- it shouldn't be different from running without DSO. When using load time weaving (LTW) with AspectJ, we have experimented with adding javaagent:<path to>/aspectjweaver.jar to the params of java command (along with the standard DSO bootclasspath param), and it has worked well. One thought -- AspectJ LTW is happening after DSO, so AspectJ wouldn't be able to reweave its advices.

Regards,

Gordon

Gordon Rose
Sr. Systems Engineer
Terracotta, Inc.
f00bar

neo

Joined: 10/25/2006 04:50:01
Messages: 3
Offline


I am pursuing an architecture where all my "data objects" behave as simple, in-memory JavaBeans. I want to avoid database mapping and database query languages (be they SQL, SODA etc.)
 


I've been toying with this idea as well, but how do you query objects for that you have no reference for?

For example, how could you write an arbitrary query given a set of constraints to produce a result list of something? Or a report?

I guess one naive way to do this would be to index what you overflow to disk - and if the overflowing is transparently handled by the OS swap mechanism, I guess you could just index your entire object population (like a database). Having said that, you would probably need to have a index on everything that hasn't been swapped out as well - a unified index.

One possible solution would be to use something like dbd as an embedded database, which would take care of a lot of the low level stuff for you.
grose

journeyman

Joined: 08/04/2006 07:58:08
Messages: 17
Location: Terracotta, Inc.
Offline

Hi f00bar,

I like the handle, by the way. Without going into too much detail regarding future product direction, which I can't as this is a public forum, I can say several customers have asked us how they could use our disk-backed clustered POJOs as a kind of object database. We are looking at several alternatives as to how we might do this.

However, a doable solution today is simply to make multiple references to an object in more than one collection, using the values of different fields for keys -- or for instance, mix collection types -- use a linked list for sequential access to a set of objects and a map for key-based access. If those collections are shared using Terracotta, you can easily access the appropriate collection for the desired member whether at the moment you have a reference to that object or not. Terracotta is intelligent about how it loads collections into a client VM. Since they can be arbitrarily large and deep, using a map as an example, Terracotta only loads the key and the top level of the value (the depth to which the graph of the value is loaded is configurable). So in reality, you can keep a very, very large collection "in memory", iterating over the keys and referencing members of the collection only as needed. The Terracotta client faults those in only when you access them (and by the way can silently release memory used by shared objects w/o affecting the application in order to optimize memory use on the client).

Regards,

Gordon

Gordon Rose
Sr. Systems Engineer
Terracotta, Inc.
 
Forum Index -> Terracotta Platform
Go to:   
Powered by JForum 2.1.7 © JForum Team