Re: Serialized Access
| От | Phillip Mills |
|---|---|
| Тема | Re: Serialized Access |
| Дата | |
| Msg-id | dd0408e50806260534l68b9703ayfb364b9bcfd33662@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Serialized Access (Craig Ringer <craig@postnewspapers.com.au>) |
| Ответы |
Re: Serialized Access
|
| Список | pgsql-general |
On Wed, Jun 25, 2008 at 10:21 PM, Craig Ringer <craig@postnewspapers.com.au> wrote:
Thank you very much for this and the link. (I'm much more an OOP programmer than a DB programmer.) Too bad about the non-portability, but I suppose it had to be.
I am a little bemused that the only supported Java persistence strategy is to try the operation, and then react to failure by recreating the entire transaction. At first I assumed I could catch the exception and then re-do the one table operation that had failed...nope, not in a transaction any more.
You might want to look into advisory locking. If your locks don't need
to be longer than the life of an active EntityManager session then you
can probably just issue a native query through the EntityManager to
acquire the lock before doing anything more.
Thank you very much for this and the link. (I'm much more an OOP programmer than a DB programmer.) Too bad about the non-portability, but I suppose it had to be.
I am a little bemused that the only supported Java persistence strategy is to try the operation, and then react to failure by recreating the entire transaction. At first I assumed I could catch the exception and then re-do the one table operation that had failed...nope, not in a transaction any more.
В списке pgsql-general по дате отправления: