retrieve the key from a map

[ralf]

If your application is such that you have to consider memory use so carefully,
then it is is certainly worth your while creating your own implementation of
Map which has all the features you need and lacks ones you don't. (E.g you
probably wouldn't want the object count overhead of using the Entry objects,
but would just have two or three parallel arrays to hold keys, values, and
counts).

I want to switch to pcj.sourceforge.net somewhere in the future. pcj
does open hashing, so there are no Entry-objects anyway. Unfortunately
pcj still does not support an equivalent to LinkedHashMap, so I still
have to use Java Collections.

If pcj supported a LinkedHashMap and a getKey()-function, then this
would perfectly fit my requirements. So I rather will extend pcj
somewhere in the future then implementing my own hashmap.

Ralf.

 

[ralf]

Wrapping values into another class is also not an option for the same

But the same is true for your approach of putting the counter into the
key class (unless I am missing something).

I need my own key class anyway. The key is the database query, which
consists of one or more objects, so I need a container class anyway.
There is almost no additional cost for putting the counter there.
Values are java.util.List, and don't want to implement my own List just
for adding the hit counter. Maybe, some day I will use arrays instead
of Lists (for saving even more memory), then this will not work anyway.

Even then you should care about design. Someone will have to maintain
this X months from now and he / she will be thankful if you do.

This is just a deal between performance and simplicity. Since I do
write a persistence framework which will (hopefully) be reused many
time, I tend to prefer performance.

Is it caching queries or query results? Also, if it's query results,
why do you have to cache them across transactions? This might lead to
inconsistencies.

Its caching results. Of course, as long as this cache is activated, one
must not modify the database contents bypassing the framework. If this
is intended, this cache must be deactivated. For clustering, there will
be a special invalidation notification, but this is not yet
implemented.

Best regards
Ralf.

PS completely OT:
I see, you don't use google groups for posting. Which NNTP server do
you use? I could not find one, that allows posting.

 

[Robert Klemme]

I need my own key class anyway. The key is the database query, which
consists of one or more objects, so I need a container class anyway.
There is almost no additional cost for putting the counter there.

Compared to the overhead you pay for the list and the objects that make
up your values the overhead of an additional object that encapsulates
values and counts seems negligible. This smells a bit like premature
optimization.

Its caching results. Of course, as long as this cache is activated, one
must not modify the database contents bypassing the framework. If this
is intended, this cache must be deactivated. For clustering, there will
be a special invalidation notification, but this is not yet
implemented.

Just out of curiosity: what features does your persistence framework
provide that existing frameworks do not?

PS completely OT:
I see, you don't use google groups for posting. Which NNTP server do
you use? I could not find one, that allows posting.

http://news.individual.net/

Pretty reliable and a lot of groups but comes with a small cost. I was
annoyed with trouble I had with free newsservers so I switched over.

Kind regards

robert

 

[ralf]

Compared to the overhead you pay for the list and the objects that make

up your values the overhead of an additional object that encapsulates
values and counts seems negligible. This smells a bit like premature
optimization.

May be. I did not yet do any real memory consumption test. I probably
will do really soon. But until then I think, every object counts - at
least for objects in the global cache (that will go into old-gen) and
for numbers of objects growing with the size of the cache.

I'm also a bit annoyed, because the functionality I need is neither
difficult to implement (for the JCF) nor ugly design. My way of storing
the hits counter may be ugly, but providing the getKey functionality is
not. It's a one-line-method, and it has just been forgotten.

Not that I want to do any JCF-bashing. In fact I think, JCF is one of
the most well designed libraries ever written for Java. And Java is one
of the best (general purpose) programming languages ever implemented.

Just out of curiosity: what features does your persistence framework
provide that existing frameworks do not?

I really like static type safety. Within my framework, its a
compile-time error to assign a double value to a persistent field of
type string. Its also a compile-time error to compare a string field to
a double value (or a double field) within a database query. Same with
using the "like" operator on a double field. And of course, queries for
customer objects return a Collection<Customer>. Removing a persistent
field or class from the schema gives you compile-time errors, whereever
you used it (including database queries of course, not just
getters/setters). Renaming a persistent field or class using a modern
Java IDE really renames all references to that field, including those
in queries. No more "column not found"-SQLExceptions. I *hate* writing
database queries in some plain text language.

Second I don't like writing XML (or any other external, non-java)
description of the persistent schema. Within COPE (did I mention the
name of the framework already ), everything is specified within
your Java source code. Everything. Persistent classes, fields,
constraints, queries.

And I want support for migrating the database to new versions of the
application without loss of data. For instance, if you add a new
persistent field to the schema you must not forget to add a new column
to the database table. For COPE there is a helper application telling
you which column (or table or constraint) is missing (or not used any
longer) and lets you create (drop) it with a single click. I really
missed this in my projects, because it's another typical source of that
"column not found"-SQLExceptions.

And I don't want to waste my time remembering, which column type can
store a string up to 400 characters most efficiently with that
particular database I'm using right now. Was it "varchar(400)" or
"varchar2(400)" or "text" or "tinytext" or just "string" ? Grmpf. COPE
does that for you.

Ooops. Got a bit lengthy .
And of course the cache will be the most effifcient on earth when it's
ready, but it's not yet.

There is also a website, with some explanation:

http://cope.sourceforge.net/

http://news.individual.net/

Pretty reliable and a lot of groups but comes with a small cost. I was
annoyed with trouble I had with free newsservers so I switched over.

Thanks a lot. I just registered.

Best regards,
Ralf.

 

[Robert Klemme]

May be. I did not yet do any real memory consumption test. I probably
will do really soon. But until then I think, every object counts - at
least for objects in the global cache (that will go into old-gen) and
for numbers of objects growing with the size of the cache.

Btw, did you also consider using a LRU cache? It's pretty easy to
implement and has little run time overhead.

Just out of curiosity: what features does your persistence framework
provide that existing frameworks do not?

I really like static type safety. [snip]

I think this is dealt with by existing implementations of OOR mappings.

Second I don't like writing XML (or any other external, non-java)
description of the persistent schema. Within COPE (did I mention the
name of the framework already ), everything is specified within
your Java source code. Everything. Persistent classes, fields,
constraints, queries.

EJB 3.0 and Hibernate can also use Java 1.5 annotations.

And I want support for migrating the database to new versions of the
application without loss of data. For instance, if you add a new
persistent field to the schema you must not forget to add a new column
to the database table. For COPE there is a helper application telling
you which column (or table or constraint) is missing (or not used any
longer) and lets you create (drop) it with a single click. I really
missed this in my projects, because it's another typical source of that
"column not found"-SQLExceptions.

I'm not sure what EJB and Hibernate do about this but since this is such
a common scenario I bet they have solved this already.

And I don't want to waste my time remembering, which column type can
store a string up to 400 characters most efficiently with that
particular database I'm using right now. Was it "varchar(400)" or
"varchar2(400)" or "text" or "tinytext" or just "string" ? Grmpf. COPE
does that for you.

Again, EJB and Hibernate deal with that, too. There is also db4o which
also has nice querying features IIRC: http://www.db4o.com/

Ooops. Got a bit lengthy .
And of course the cache will be the most effifcient on earth when it's
ready, but it's not yet.

Certainly. Sorry if I'm sounding discouraging but I have yet to see
the feature that makes your work stand out against existing solutions.

There is also a website, with some explanation:

http://cope.sourceforge.net/

Thanks for that link!

Thanks a lot. I just registered.

No sweat. Have fun!

Kind regards

robert