• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

B&S 2.2.1 - dbAccess.findByCriteria method spec requires internal database?

 
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

The B&S 2.2.1 dbAccess.findByCriteria method throws no exceptions, e.g., IOException. Therefore, in my design, I'm prepared to assume the customer intends that this method should access data in a way such that no DataInput/DataOutput operations are involved. So, as I see it, I'm constrained to 'mirror' the database file internally in my program, e.g., in a Map, to conform to the findByCriteria method spec.

Any thoughts?

Grary
 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Howdy, Grary!

So, as I see it, I'm constrained to 'mirror' the database file internally in my program, e.g., in a Map, to conform to the findByCriteria method spec.



Do you mean something like a cache? If so, that's what I did. When my application starts, I load all database records to a memory cache. When the application finishes, I write all records back to the database. If you find yourself having to deal with a checked exception that is not in the API (for instance, an IOException in your findByCriteria method), you can always wrap this exception in a RuntimeException and throw it instead.
 
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey Grary,

I'm on B&S 2.2.1 and I haven't gone down the mirror route. I didn't (and still don't) see the point of duplicating everything from the data file in memory.

What happens if you have a power outage or something else happens that causes your application to crash? You could lose ALL your data (or at least the last updates since you synchronised with the file).

As Roberto points out, the way around the problem you mention is to create a non-checked exception to wrap any checked exceptions that may be thrown because of data access operations - that's what I've done!

Chris



 
Grary Stimon
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Gents,

Thank you for your thoughtful responses...

Roberto, with regards to memory caching, I had tentatively taken this route using Collection containers to store record data (is that the containment we mean for cacheing?)
Unfortunately, I am getting out-of-memory heap complaints in Eclipse (using preallocated 256MB.) I am not sure what to do next, because I don't want to risk that the Sun reviewers would encounter the same exception. I had been warned by veteran programmers there would come a day when I would have to enlarge the heap, but I don't know if the SCJD is the place to do it.

So, maybe I should take the other proposal which is to use a non-checked (runtime) exception. As I think I've seen debated elsewhere in this forum, a checked exception is really more appropriate to handle any IOExceptions thrown during database disk file read/writes, while runtime exceptions are thought of as indicating programming errors.

Thanks to both commenters...

Grary
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Grary,

I also used a record cache and i used a (Hash)Map containing record numbers as key and the record as value. And i didn't get any OutOfMemory problems (database file contains approx 30 records). I used eclipse too and didn't change anything to the default settings. So i guess you have some issue with how you create your collection container. or maybe it is an issue with installation of eclipse.
and of course if the db keeps growing and growing you will have a problem regarding memory. so you have to address this in your choices.txt: telling this record cache is good for now, but in the future it could cause some memory problems and so you can give some alternative to solve that issue (in some future release of the program), like not loading any record from the past because these records can't be booked. Show the accessor that you did some thinking about your solution and that you have thought about possible problems and solutions.

regarding your remark about the exceptions. you should think that you have to implement an interface, which you are not allowed to change. so you can't throw a checked exception from the read method (when ioexception occurs), because the interface doesn't allow that. So throwing a runtime exception instead is the only way you can cope with these IOException.

and in my opinion using a record cache simplifies your code a lot. reading/writing to the file is just in 2 methods (an initialize method to fill your cache, and a stop-method to write cache back to file). in all the other methods you are just accessing a map.

Just my 2 cents.
Kind regards,
Roel
 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Grary Stimon wrote:Unfortunately, I am getting out-of-memory heap complaints in Eclipse (using preallocated 256MB.) I am not sure what to do next,
...
I had been warned by veteran programmers there would come a day when I would have to enlarge the heap, but I don't know if the SCJD is the place to do it.

you can use a profiler to find out why you have memory problems. With the number of records we have, you should not have any heap problem.

No, you are not allowed to use any jvm arguments. I guess you have something similar to this statement "Your programs must not require use of command line arguments other than the single mode flag, which must be supported."
 
Vasya Pupkin
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Roel De Nijs wrote:
and in my opinion using a record cache simplifies your code a lot. reading/writing to the file is just in 2 methods (an initialize method to fill your cache, and a stop-method to write cache back to file). in all the other methods you are just accessing a map.

I am surprised you got away with this approach. If your server works for a couple of weeks without stopping and then computer crashes, then you loose all the data for the whole month.
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Vasya Pupkin wrote:I am surprised you got away with this approach. If your server works for a couple of weeks without stopping and then computer crashes, then you loose all the data for the whole month.


Of course I addressed this issue in my choices.txt and explained some ways to handle it in future releases
 
Grary Stimon
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Roel,

It turns out my OutOfMemory error was due to a logic error and not cache size...

The reason I'm inclined to follow your approach (and Roberto's) is to satisfy the createRecord() DuplicateKeyException, no-exception findByCriteria() specification and, generally, to facilitate read operations. As regards write operations, my approach is to write to both to the disk and then to the cache, so my design choice doesn't allow any unusual data-loss risk.

Thanks to all commenters,

Grary
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic