Re: Performance/Issues with CMP and JBoss - Mailing list pgsql-general

From James Robinson
Subject Re: Performance/Issues with CMP and JBoss
Date
Msg-id 9D1BFA8C-BD83-49D2-BD00-D459AA1F734B@socialserve.com
Whole thread Raw
In response to Performance/Issues with CMP and JBoss  ("Andy Dale" <andy.dale@gmail.com>)
List pgsql-general
Diagnosing JBossCMP issues is not for the faint of heart, in that one
of its main raison d'etre's is to hide SQL knowledge away from the
casual coder. Add into the mix the concurrency issues which naturally
occur since an EJB container is multithreaded and the overly
complicated JTA stuff and you've a real mess to diagnose when things
don't work just so.

When we ran CMP, we'd also run postgres in debugging mode so as to
have it emit queries onto stdout so that we could watch exactly what
the CMP was doing. Try starting up postgres ala:

    /usr/local/pgsql/bin/postmaster -d 2 -i -D /usr/local/pgsql/data
2>&1 | grep LOG

Your mileage may vary, as would your PGDATA dir etc. Read the docs on
the postmaster. But the end result is the ability to watch each query
fly by on your development machine -- letting you see the order of
which updates, inserts, selects, and commits happen from the postgres
backend's perspective.

I suspect the original poster has code issues being tickled by java
threading issues interacting poorly with their default transaction
isolation level of READ COMMITTED -- their inserts are being done in
one thread / JTA transaction, while the read is being done in another
and is loosing the race -- the inserting thread has not committed
yet. Running the backend in debugging mode should let you see the
select happening _before_ the first thread has committed its
transaction. Postgres is doing exactly what it is being told -- if
the inserting transaction has not yet committed, and the reading
transaction's isolation level is set to READ COMMITTED, then postgres
_will_not_ return anything to the reading connection / thread which
has not yet been committed.

Good luck with reading and following all of the EJB and CMP
specifications, the JBossCMP documentation, the JTA spec, and then
swallowing all of postgres [ or any other SQL backend ]. If you don't
have all of 'em fully understood yet, you will have to one day if you
continue with all that fat tech which was supposed to make things
easy for you. CMP is a very leaky overcomplicated abstraction.

----
James Robinson
Socialserve.com


pgsql-general by date:

Previous
From: "Eric Andrews"
Date:
Subject: Re: proper use of array datatype
Next
From: "Thomas F. O'Connell"
Date:
Subject: PostgreSQL on RAM Disk / tmpfs