object relational database versus "inteligent" serialization
in [Java Programming]
|
From: markspace on 9 Feb 2010 13:23 luc peuvrier wrote: > > We do not work on restricted environment, but ours customer do not > give to us so much memory on their server in wich application is > installed. In only one case we have enough memory; it is when we sale > the server with embedded application, it only run linux and our > application. But plenty of customers do not want a new PC in their > office. > We can also imagine use a 32Gbyte solid state ram-disk, there is some > we 15 days battery backup, or replication in flash memory. OK, I would call that a restricted or embedded environment. Not quite JME, but still pretty small footprint. You might want to mention that in your documentation. Another ORM persistence layer is probably not needed, but one that runs in a much smaller memory footprint might be useful. > An important point is we have to persist data to be able to stop and > restart the application, we do not do that so often. This also should be mentioned in your documentation. Performance does not seem to be an issue, you might be slower than a regular ORM layer, or unable to do efficient random access.
From: Martin Gregorie on 9 Feb 2010 14:47 On Tue, 09 Feb 2010 10:23:13 -0800, markspace wrote: > luc peuvrier wrote: > > >> We do not work on restricted environment, but ours customer do not give >> to us so much memory on their server in wich application is installed. >> In only one case we have enough memory; it is when we sale the server >> with embedded application, it only run linux and our application. But >> plenty of customers do not want a new PC in their office. > >> We can also imagine use a 32Gbyte solid state ram-disk, there is some >> we 15 days battery backup, or replication in flash memory. > > > OK, I would call that a restricted or embedded environment. Not quite > JME, but still pretty small footprint. You might want to mention that > in your documentation. Another ORM persistence layer is probably not > needed, but one that runs in a much smaller memory footprint might be > useful. > > > > An important point is we have to persist data to be able to stop and > > restart the application, we do not do that so often. > > > This also should be mentioned in your documentation. Performance does > not seem to be an issue, you might be slower than a regular ORM layer, > or unable to do efficient random access. > Start up speed can be important. Maybe Luc has start up time requirements and starting from a database doesn't meet them. The following story describes such a case: I worked on a system that used a very large red-black binary tree for fast lookups on a non-static key set. This was done for performance reasons - we couldn't crack 300 lookups/sec doing the lookups on the target RDBMS and hardware, but needed at least 7000/sec to handle incoming data volumes. The red-black tree implementation ran at 25000/sec with about 200M keys. First cut implementation loaded its tree from the database BUT took 40 mins to start up. Too slow, so it was rewritten to periodically dump the tree into a set of binary files and to restart from the files after a tidy shutdown. Result: a sub-5 minute startup, but with the ability to restart from the database after a crash. This system was written in ANSI C. However the same start up requirements could easily apply to a similar Java implementation. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: luc peuvrier on 9 Feb 2010 15:01 joafip is based on red-black tree, it use a heap implementation ( indexed binary data record ). About performance in 2008 I made the following measurement http://joafip.sourceforge.net/perf/perf.html The object saved have few bytes. For the test a TreeMap is persisted. A colleague validate the performance for our application usage, he was more worry about hibernate/postgres performance when integrating item table. I have not value to give to you. Luc
From: Pitch on 9 Feb 2010 15:13 In article <hks15c$7lg$1(a)news.albasani.net>, noone(a)lewscanon.com says... > > Pitch wrote: > > I didn't know parent default contructor is automatically called in > > child's constructor (if no other parent contructor is called). > > It would have to be - you cannot construct an object unless all its superclass > aspects are constructed, in Java's case before subclass aspects. > > > So you cannot override parent's default contructor - which sucks. > > Why does it suck? > > You cannot override any constructor, not default, not explicit no-arg, not > with args. > > > Also, you cannot place any code before super(...) which I already new, > > and it also sucks. :) > > Again, why does that suck? > > > Anyone knows why is that so? > > You do, if you give it two minutes' thought. You call a method or do whatever > in a constructor after the object has reached a certain level of construction. > In order to reach that level, the superclass aspects have to be constructed > first, even to reach the subclass's constructor aspect. If you want something > other than default superclass construction, you have to do it first. So you all say it's a safety thing, right? It forces a design where initialization of an object gurantees that all inherited initializations will execute first. Nice. ;) But many other languages allow you to override constructors! Are they old, obsolete? Are there any other reasons besides good design? If we talk about errors that may occur if you could override a constructor then we could say those same erros could occur if you override any other protected method. Why is proper construction sequence so important? Why not just leave it to access modifiers? Wouldn't that be more straightforward than having silly rules like "super() must be the first line"?? I mean, if it's a call, and not a syntax issue I'd like to write it wherever I like. Let _me_ worry about proper initialization. :) -- stirr your cofee properly
From: Lew on 9 Feb 2010 16:50
Pitch wrote: > So you all say it's a safety thing, right? It forces a design where Not exactly. It's more like there has to be an object before you can call methods on it. (The area where I was wrong.) There has to be an object before you can do anything at all to it, really. > initialization of an object gurantees that all inherited initializations Construction, of which initialization is a part. > will execute first. That's just the way Java is designed. There are tradeoffs to construction parent-first vs. subclass-first. The Java approach simplifies things, but as you see, you have to use static methods to accomplish fancy logic in a 'super( foo )' call. > But many other languages allow you to override constructors! Are they > old, obsolete? Which languages? The answer to that will tell you if they're old or obsolete. > Are there any other reasons besides good design? No doubt. Mainly it's to ensure that anything you do on an instance happens on completely-constructed parts. > If we talk about errors that may occur if you could override a > constructor then we could say those same erros could occur if you > override any other protected method. Not true. First of all, you have to bear in mind that you cannot override constructors in Java, nor inherit them. As for overriding any other non-private method, there is a difference between the errors that occur when an object is not constructed yet vs. once it's completely built. > Why is proper construction sequence so important? Why not just leave it > to access modifiers? Wouldn't that be more straightforward than having > silly rules like "super() must be the first line"?? No. And calling the rule "silly" doesn't make it so. Several have answered you to explain why it's not silly. That you call it that now, after having read those replies, means that you are being obstinate. The reasons behind the decision are sound, and like all engineering decisions, do involve tradeoffs. That you are not able to perform some idiosyncratic action that only you really want to do does not make Java's decision silly. As for "leaving it to access modifiers", that would not address at all what construction order addresses. You can put access modifiers on constructors; that has no effect on construction order. The purpose of construction order is to make sure that an instance exists before you do stuff to it. The purpose of access modifiers is to affect access, whether before, during or after construction. And no, it would not be more straightforward than constructing objects from the inside out. Allowing code prior to superclass construction, or this-class construction for that matter, would complicate matters horribly. > I mean, if it's a call, and not a syntax issue I'd like to write it > wherever I like. Let _me_ worry about proper initialization. :) I really don't think that would be wise. What do you mean by "a call, and not a syntax issue"? In fact, the issue of construction order is neither, whatever you might mean by that. It's a matter of having an object on which to act. -- Lew |