PhWorks has announced the availability of PhDataCache Version 1.0. PhDataCache is a lightweight caching JDBC driver that is free for non-commercial use and comes with full source code. A caching JDBC driver sits between an app and JDBC driver, intercepting JDBC calls and caching resultsets based on pre-defined rules.

Visit phworks for more
information.

Press Release
--------------------------
PhWorks is pleased to announce the availability of PhDataCache Version 1.0. PhDataCache is a lightweight caching JDBC driver. With its combination of low cost and easy configuration, PhDataCache is ideal for anyone who needs a quick and easy way to boost database performance.

PhDataCache is free for non-commercial use and comes with full source code.

Visit phworks for more
information.

PhDataCache brings to server designers a simple yet powerful database cache at a cost that everybody can afford. As a caching JDBC driver PhDataCache sits between your application and your database JDBC driver. It intercepts all of your JDBC calls and, based on rules which you define, determines whether or not to cache query responses. You have complete control over what gets cached and for how long, and because it uses the well defined JDBC interface, you needn't change a line of code in your application!

And as if that weren't enough, PhDataCahe is free for non-commercial use and comes with full source code.

Features include:

- Standard JDBC interface for easy integration with your existing software.
- Simple XML defined rules to allow complete control over what gets cached and for how long.
- Easy access to runtime statistics and configuration information.
- Local query capabilities to maximise cache efficiency.
- Background refreshing to enable cache updates during periods of low application usage.
- Powerful yet simple APIs to facilitate cache management and clean up.
- Connection pooling to minimise database connection overheads.
- Explicit cache access for even finer control over caching policies

JDBC drivers really need these kind of tools.
I want to know if anyone has any comparison between this product's caching power with any CMP engines.
(One of the major advantages of CMP is caching)
Tanx
Ali Salehi

The big difference between caching at the data (relational) level and CMP caching is that the data level can answer considerably more complex queries than those supported by the CMP engine. Imagine an EJB-QL query to find the employees within a department with salary > x. The CMP implementations that I know of can only answer primary key lookups for objects from cache and possibly relationship traversals.

I'm not entirely sure what PhWork's product is capable of but I know that livestore from isocra can answer these complex queries.

Cheers,
- Dean
www.isocra.com

I would assume that performance would be best if the data was cached in the format that was closest to its end usage, i.e. if you are loading an object than you want to load that object as quickly as possible. Caching the result sets still means that objects need to be instantiated and setup even if the underlying result set is cached.

Hi Bruce

"Caching the result sets still means that objects need to be instantiated"

I think that's a fair comment. Clearly an object cache has advantages over a simple results set cache. There are a number of other things to consider as well however. First, you still get the benefits of reduced database contention, network overheads and parameter marshaling and parsing. Second, by caching at this level anyone who is not using EJBs or JDOs still has access to a caching mechanism. One of our aims was to make this cache as widely applicable as possible, but you're right - a "one size fits all" is never a perfect solution for anyone. Hopefully its low cost will balance some of these disadvantages.

Hi

I think Result Set caching is bad idea because it very often leads to cache size explosion. Caching JDBC driver needs to maintain in-memory database and maintain relations between tables that exists in database in order to be efficient, like other commercial caching JDBC drivers do (see older news and discussions on TSS)

Regards,
Mileta

Caching of db results can be useful in some situations, but what some people forget is that this is what all "good" databases do anyway.

So, often you are competing against the caching algorithms of the database itself. Usually the database has been developed over many years and it's caching is very highly optimised, thus you can often actually degrade performance by doing this in the general case.

Tim

"Caching of db results can be useful in some situations, but what some people forget is that this is what all "good" databases do anyway."

Surely it depends on how you access the database. If you access a database across a network then this type of caching can make quite a big improvement on performance.

If you had the database on the same physical server as the database then you might not see any big improvements.

Dan

"If you had the database on the same physical server as the database then you might not see any big improvements."

I am talking rubbish here!

I meant to say.....

If you had the database on the same physical server as your web application then you might not see any big improvements.

Dan

Hi Mileta

"Caching JDBC driver needs to maintain in-memory database and maintain relations between tables that exists in database in order to be efficient"

You're quite correct. Some thought does indeed need to be given into what gets cached and what does not. If your application returns a thousand distinct rows for every query then I certainly wouldn't recommend caching those directly.

PhDataCache does have the ability to store tables and views internally and to perform simple queries locally. We've tried to target what we considered the most likely type of queries in typical web based scenarios, but we recognise that this will not fit everyone's needs and that the products capabilities will have to evolve over time.

Regards

Peter Hearty
Chief Engineer, phWorks
http://www.phworks-online.com

Tel: +44 (0) 20 7511 0737
Fax: +44 (0) 870 458 1627
Email: peter.hearty@phworks-online.com

I read the documentation but it seems that cache invalidations are only based on timeouts. Does this mean that no cache invalidation can be based on write queries (insert, update, ...) going through the driver ?

Emmanuel

Mileta

"Caching JDBC driver needs to maintain in-memory database and maintain relations between tables that exists in database in order to be efficient, like other commercial caching JDBC drivers do (see older news and discussions on TSS)"

I haven't tried this software myself, but I have used InstantDB that was written by Peter. If anyone understands the problem domain then I think he would.

I guess it takes someone that can write a full database to write a product like this!

Are there any peformance stats available?

Dan

Hi Dan

Nice to hear from you again. Where are you hangin out these days?

To answer your question on the stats front. The trouble is that stats on this type of thing are just too application specific to be really meaningful. I could easily contrive scenarios where I could demonstrate a 10x increase in performance, throughput or responsiveness. Equally I could contrive scenarios where things get worse. I think (hope) most peeple would simply see through that type of obvious marketing hype.

Get in touch. My email's peter.hearty@phworks-online.com.

Regards

Pete

Hi Peter,

I realise performance stats are very specific to individual applications and deployment parameters. I was just interested if you had any.

Will email you later today.

Dan
P.S. Will be attending the JAG user group meeting next week if you can make it I will see you there. www.knownfuture.com/jag

Can this product manage distributed caching ? (if yes, which algorithm used)

Thanks

Hi Ali

"Can this product manage distributed caching ? (if yes, which algorithm used)"

Both the short and the long answer is "no". We don't claim to try and solve everyone's caching needs (you'll find that the readme is quite explicit about this) and are aiming to provide caching capabilities to those who perhaps have previously ruled out a database cache for cost or complexity reasons.

the isocra caching jdbc driver is the only one i've seen that claims to support distributed caching.

http://www.isocra.com/livestore/index.php

There is also an older more reliable open source called Poolman.sf.net that does a lot more and it's open source.
.V

Vic Cekvenich said:
>There is also an older more reliable open source called
>Poolman.sf.net

I tried to take a look; poolman.sf.net redirects to www.codestudio.com, which says
"PoolMan is no longer available or supported through this site. It did exceedingly well during its lifetime, and I appreciate the important role it played in so many distributed applications over the past three years. If you are looking for connection and object pooling mechanisms, they can now be found in application servers such as JRun, Tomcat and the Jakarta Project, and other J2EE products and servers."
The latest release in the SF downloads area was only a beta version and was 16 months ago. So better make that "an older more reliable and totally unsupported open source..."

Just wanted to know before trying, will it work the same way
if Connection obtained from cache/pool maintained at the App Server.
Thanks

Hi Hemant

PhDataCache switches its own connection pooling off when Connections are obtained from javax.sql.DataSource objects (or any of their descendants). You can also switch connection pooling off explicitly.

Regards

Peter Hearty
Chief Engineer, phWorks
http://www.phworks-online.com

Tel: +44 (0) 20 7511 0737
Fax: +44 (0) 870 458 1627
Email: peter.hearty@phworks-online.com