If you have a @ReadOnly annotated DAO and you try to use it to do an update, the update will be sent to the slave and it will fail with a SQLException. The error is generated by a trigger that Slony creates on tables in the slave DB to prevent you from accidentally making changes to them.

So, you then just put your annotated DAOs in your service classes and use them as you did before, right?

So, you can’t actually ever write data read from the slave back to the master because the DAO prohibits it? What happens when a service which is injected with a DAO that has a read only session factory tries to modify data, e.g. update()?

Our hibernate setup includes two separate connection definitions: one to the master DB and one to a slave DB. All write operations go to the master (obviously). *Most* read operations go to the slave (in some cases we read from the master DB, e.g. for queries where we can’t tolerate any replication latency).

We use Guice dependency injection to initialize our DAO’s with a SessionFactory, and we defined our own attributes to indicate whether a DAO should be initialized with a master DB SessionFactory (@ReadWrite) or a slave DB SessionFactory (@ReadOnly).

We’ve been talking about setting up a 3rd attribute (@Reporting) that goes to a different slave, one that isn’t guaranteed to be as up-to-date as the others but that is appropriate for “heavy” queries (for reporting purposes and such).

I wonder how one would assert that data, read from the slave, gets never written back to the master? Two session factories and more db logic in business layers?

I just installed EMS SQL Manager Lite for Postgres and I agree that it’s pretty good. The only thing it lacks is the ability to edit fields in place (in the grid view), but otherwise it looks better than the others I’ve tried. I’ll probably start using this one instead of my previous choice: DbVisualizer.

So far we’ve had pretty good luck with text search using TSearch2. We haven’t seen any records in our slow query log that involve TSearch2 queries, which means that they are all definitely under 200 ms. In our testing they were well under that (more like 10 ms). However, I should point out that our text search use cases are not particularly demanding. We use TSearch2 to look for regions (e.g. cities, neighborhoods, zip codes, etc.) whose name matches what you type into the search box. So, the number of queries is not huge and the volume of data to search is also not that big. For example, we get far more queries after the region has been identified (by name) when it’s time to look for listings that fit in that region’s polygon, and the data to search through (all listings/properties) is also much bigger.

I haven’t used Lecene myself, but a few of the other engineers here previously worked at Plum Tree, where I hear they did use Lucene. What I gather is that it gives you more functionality than TSearch2, but it comes at the cost of having to maintain your DB and Lucene in sync. Apparently there are some libraries that do some of this grunt work for you (e.g. in the hibernate OR layer), but I personally didn’t investigate those too far.

At some point we will look to support a wider range of text search features on our side, and when we do I’m sure we’ll spend time thinking about whether to stick with TSearch2 or to go with something else. For now it definitely does the job.

Kusum, to answer your question, the first step as you said would be to pull the polygon from the database, something like this:

select my_geometry_column from my_table where ST_Intersects(my_geometry_column, ST_GeomFromText(’POINT(-122.299 47.609)’,4326));

Now, this will give you the raw geometry representation, which is OK if you’re using the PostGIS libraries — you can use them to parse that binary blob and convert it into another representation that is suitable for the front-end. Alternatively, you can use the astext() function to have the DB convert the geometry data into text form.

Either way, you’ll then need to transfer that data to the client-side in order to display the polygon on the map. We use Microsoft’s Virtual Earth map API, which includes support for drawing polygons. You can learn more about that API here: http://dev.live.com/virtualearth/sdk/

Incidentally, the query you’re describing (find a polygon given a point) is different than our situation, currently. Our queries are more like “given a polygon, find all points in it”. But PostGIS supports both scenarios.

Are you able to share any experiences & stats about PostgreSQL’s full-text search performance? I have used PostgreSQL in a few production environments & can vouch for its predictability & stability, especially when coupled with OCaml. But I’ve not used the FTS feature, would prefer to use PostgreSQL’s FTS than an external solution eg Lucene.

Thanks again!
Matt

Thanks in advance
Kusum