Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Posts: 1,415
Registered: ‎07-30-2008
My Device: Not Specified

Re: SQL database?

Well, I've never checked the memory hierarchy here and I never take for granted the difference between different

cache levels on IA-32 machines but there is no disk or other device from which to load except maybe a media card or something.

There are ways to group persistent objects to save handles but you needn't worry about that now. 

And, again, AFAIK you only have stream or serial access some what like sectors on a disk. With persistent store, there

is nothing really to load. My implementation has some limitations and quirks ( String and long keys only with both having

special values that are excluded from the user ) but the approach can be generalized. For example, I have two things ( probably not a term Knuth or Stroustrupp use often but fine for now) that behave about the same but I want one to persist and not the other but otherwise

offer same interface, 


// this needs to persist

// this is only maintained while app is alive

        m_page_db = new BonsaiStringDB(0,0);

The getDB call just finds the "DB" in persistent store through a few more layers or my own junk ( this should be an OO term LOL)


 public static BonsaiStringDB getDB(String uid, String ds, int p1, int p2)
{    BonsaiStringDB db=null;
    PrefixStringStore p= XXXMobility.getRoot(uid);
    Object o=p.get(ds);


where getRoot finds the persistent hashtable object and the right data source, the bottom of the junk layers ends in something like this,


public static Hashtable getRoot() { return get_persisting(persist); }
public static Hashtable get_persisting(PersistentObject po)
    Hashtable v= null;
    // this MAY be throwing or some dumb thing on update.
    {    // need to verify documentation on synchronization issues etc   
synchronized (po) {
    try {
        Object o=po.getContents();
        if (o instanceof Hashtable)



So, anyway, I endup with a reference to a "DB" object that exposes indicies determined by the developer much

as with setting up any other DB. I have gone with numerical indicies ( and yes I have gotten mixed up sometimes LOL)

but it isn't hard to see how you create indicies on retrieval values ( things like date ). My api happens to make index entries

iterators and it isn't really different from the jdbc ResultSet AFAIK. For simple "queries" ( again, there aren't really any queries

as much as tree searches), this means the code just picks an  index and does a find on that tree. The result is

an iterator,



 BonsaiIndex bi=p.itor(urkey,0);
    if (bi==null) return tot;

// this itor lookup is just a special type of find to handle cases where specific key does not exist

// inc is a special string increment ( don't ask ). 

    BonsaiIndex ei=p.itor(urkey,0);

    // ei apparently is sometimes coming back equal to bi???
    // AFAIK, the above observation related to faulty increment  not the b-trees,
    while (bi!=ei)
        PrefixStringStore px=(PrefixStringStore)bi.getTarget();
        BonsaiIndex ii=px.m_first;
        while (ii!=null)
            targetRecordType pc= (targetRecordType) ii.getTarget();

// whatever you would do with a result set here...













New Member
Posts: 1
Registered: ‎04-28-2011
My Device: Blackberry Torche
My Carrier: AT&T

Re: SQL database?

To answer your questions, our performance benchmarks in 2009 were against mobile databases from the following:


  • IBM
  • Oracle
  • Sybase
  • Microsoft
  • FirstSQL 

Our database is significantly smaller and dramatically faster than all of these databases with comparable features and in some cases, significantly more features.


Since that time, we have also benchmarked the database against SQLite and we run at approximately 2X to 4X faster than SQLite on Android and Blackberry and provide type safe data storage, 2D and 3D geospatial compliance, etc. 


You asked why use a database?  There are many reasons, but a few include better storage and retrieval performance than simply storing to RMS or PersistentObject locations, common SQL commands, portability of applications across platforms, easier testing of applications across platforms, integrated features for encryption, UTF-8, communications, etc.   Also for RMS storage, we provide a capability to use multiple RMS storage locations and being able to search across all RMS storage locations from the database rather than dealing with the RMS size limitations.  There are a lot of reasons to use a database.