Hello Silvio,
I investigated that: we get ConstraintViolationException with Oracle
and
WrappedSQLException in Postgres. That depends on
SqlExceptionTranslator.sqlException(), which can translate
Oracle-specific errors but not Postgres ones.
This is not good. We actually shall fix the code
On 09/05/2013 02:26 AM, Jan Pazdziora wrote:
Please note that this will not work -- the fact that you check content
of some table in your session and your transaction and based on that
run the insert operation does not mean that the other session cannot
do exactly the same, both will find the
On 09/03/2013 02:33 PM, Tomas Lestach wrote:
to be honest, I personally do not like seeing DB index names in
the application code.
I agree that it is not really an elegant solution, but I could not find
another way of ignoring such specific exceptions. Ideas welcome :-)
(Btw. does it work on
(Btw. does it work on PG, when the index name is stated uppercase?)
Actually, we could not reproduce the problem in Postgres at all.
This is interesting.
Isn't it possible to use 'SELECT FOR UPDATE' in these cases?
I do not really think so, because AFAIU there is actually no SELECT
On Wed, Sep 04, 2013 at 08:35:27AM +0200, Silvio Moioli wrote:
On 09/03/2013 02:33 PM, Tomas Lestach wrote:
to be honest, I personally do not like seeing DB index names in
the application code.
I agree that it is not really an elegant solution, but I could not find
another way of ignoring
On Wed, Sep 04, 2013 at 08:35:27AM +0200, Silvio Moioli wrote:
That would mean saving snapshot IDs between HTTP requests. Again,
doable, but sounds quite difficult at least to me!
Yet another possibility would be to INSERT only tuples not already
present by set difference, something like
Hello Silvio,
to be honest, I personally do not like seeing DB index names in
the application code.
(Btw. does it work on PG, when the index name is stated uppercase?)
Isn't it possible to use 'SELECT FOR UPDATE' in these cases?
(The other transaction would need to wait till the first one
I'm a little rusty on my Oracle but in PostgreSQL I think this could
be resolved using the Isolation level within the transaction, and
possibly snapshots within the transaction
http://www.postgresql.org/docs/9.2/interactive/sql-set-transaction.html
An other possibility is to request an exclusive
Hi,
The attached patch attempts to fix an issue we found while running some
Selenium-based automated UI tests. Basically multiple requests that
involve an RhnSet can overlap if the user is clicking very quickly and
that might result in an ISE because RHNSET.RHN_SET_USER_LABEL_ELEM_UNQ
is
