You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Marco de Booij <md...@scarlet.be> on 2012/06/17 17:17:38 UTC
Postgres sequence: current transaction is aborted
Hello,
I have been searching on the internet for a solution of 'my' problem:
ERROR: current transaction is aborted, commands ignored until end of
transaction block {prepstmnt 253501751 SELECT
NEXTVAL('DOOS.SEQ_I18N_CODES')} [code=0, state=25P02]
I found questions on this dating back to 2000 but not clear answer (to
me) on how to solve it.
What do I have? A class to persist:
@Entity
@Table(name="I18N_CODES", schema="DOOS")
@SequenceGenerator(name="SEQ_CODE_ID", schema="DOOS",
sequenceName="SEQ_I18N_CODES")
public class I18nCodeDto extends Dto
implements Comparable<I18nCodeDto>, Cloneable {
@Id
@GeneratedValue(strategy=GenerationType.SEQUENCE,
generator="SEQ_CODE_ID")
@Column(name="CODE_ID", nullable=false)
private Long codeId;
@Column(name="CODE", length=100, nullable=false, unique=true)
private String code;
@OneToMany(fetch=FetchType.EAGER)
@JoinColumn(name="CODE_ID")
@OrderBy("id.taalKode ASC")
private List<I18nCodeTekstDto> teksten = new
ArrayList<I18nCodeTekstDto>();
The class has the getters and setters that are needed. The user that
connects to the datasource has access to the sequence and the tables. I
get the error when I try to persist the object.
i18nCodeComponent.insert(i18nCode);
The insert ends up in a create method:
/**
* Persist de DTO
*
* @param dto
* @return
* @throws DoosRuntimeException
* @throws DuplicateObjectException
*/
public T create(T dto) throws DoosRuntimeException,
DuplicateObjectException {
if (getEntityManager().contains(dto)) {
throw new DuplicateObjectException(DoosLayer.PERSISTENCE, dto,
"bestaat reeds");
}
getEntityManager().persist(dto);
getEntityManager().flush();
getEntityManager().refresh(dto);
return dto;
}
My question is how I solve this problem?
I tried it with Postgres 8.4 and 9.1 with the jdbc drivers for this
version and it failed in both cases. The code worked fine when I used
MySQL with auto-increment (with the correct @GeneratedValue :-) ) and
with Oracle Sequence + Hibernate it also works.
I use apache-tomee-plus-1.0.0.
Regards,
Marco
Re: AW: Postgres sequence: current transaction is aborted
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Marco,
Yes, I am updating the OpenJPA-2196 JIRA with pertinent information from
this discussion. Thanks for your help in debugging the issue(s).
Kevin
On Wed, Jun 20, 2012 at 10:42 AM, Marco de Booij <md...@scarlet.be> wrote:
> Hi Kevin,
>
> You answered for me but I want to clarify it for John.
>
> The GRANT SELECT, UPDATE, INSERT, DELETE only works for data in a table
> (For a sequence you only need SELECT and UPDATE). The solution in openJPA
> for the sequence involves a change in the definition of the SEQUENCE. In
> PostgreSQL I have not found the way to grant this right so the user that is
> used in the application must be the owner of the sequence. In Oracle this
> is possible with GRANT ALTER. This is different from the table solution
> that you mention. The table solution however is more generic (and supports
> rollback) since not all databases support the SEQUENCE.
>
> Thanks for all the help. For me this thread is finished. I can now use the
> SEQUENCE. I hope that in one of the next versions we can bypass this ALTER
> SEQUENCE statement.
>
> Regards,
>
> Marco
> Op 20-06-12 15:50, Boblitz John schreef:
>
> Hi Keven,
>>
>> Oh.
>>
>> The same GRANT will work though - no need to play with ownership.
>>
>> Cheers!
>>
>> John
>>
>> -----Ursprüngliche Nachricht-----
>>> Von: Kevin Sutter [mailto:kwsutter@gmail.com]
>>> Gesendet: Mittwoch, 20. Juni 2012 15:32
>>> An: users@openjpa.apache.org
>>> Betreff: Re: Postgres sequence: current transaction is aborted
>>>
>>> Hi John,
>>> In this case, Marco was using a database Sequence, not the
>>> OpenJPA sequence table. There was an issue with having
>>> permissions to alter the Sequence with Postgres. Just wanted
>>> to clarify. Thanks!
>>>
>>> Kevin
>>>
>>> On Wed, Jun 20, 2012 at 12:57 AM, Boblitz John
>>> <Jo...@bertschi.com>**wrote:
>>>
>>> You can set the permissions for the table with:
>>>>
>>>> GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE
>>>> [SchemaName].openjpa_sequence_**table TO [UserName];
>>>>
>>>> *NOTE: This Sequence Table was autogenerated by openJPA - you name
>>>> might be different!
>>>>
>>>>
>>>> John
>>>>
>>>>
>>>>
>
Re: AW: Postgres sequence: current transaction is aborted
Posted by Marco de Booij <md...@scarlet.be>.
Hi Kevin,
You answered for me but I want to clarify it for John.
The GRANT SELECT, UPDATE, INSERT, DELETE only works for data in a table
(For a sequence you only need SELECT and UPDATE). The solution in
openJPA for the sequence involves a change in the definition of the
SEQUENCE. In PostgreSQL I have not found the way to grant this right so
the user that is used in the application must be the owner of the
sequence. In Oracle this is possible with GRANT ALTER. This is different
from the table solution that you mention. The table solution however is
more generic (and supports rollback) since not all databases support the
SEQUENCE.
Thanks for all the help. For me this thread is finished. I can now use
the SEQUENCE. I hope that in one of the next versions we can bypass this
ALTER SEQUENCE statement.
Regards,
Marco
Op 20-06-12 15:50, Boblitz John schreef:
> Hi Keven,
>
> Oh.
>
> The same GRANT will work though - no need to play with ownership.
>
> Cheers!
>
> John
>
>> -----Ursprüngliche Nachricht-----
>> Von: Kevin Sutter [mailto:kwsutter@gmail.com]
>> Gesendet: Mittwoch, 20. Juni 2012 15:32
>> An: users@openjpa.apache.org
>> Betreff: Re: Postgres sequence: current transaction is aborted
>>
>> Hi John,
>> In this case, Marco was using a database Sequence, not the
>> OpenJPA sequence table. There was an issue with having
>> permissions to alter the Sequence with Postgres. Just wanted
>> to clarify. Thanks!
>>
>> Kevin
>>
>> On Wed, Jun 20, 2012 at 12:57 AM, Boblitz John
>> <Jo...@bertschi.com>wrote:
>>
>>> You can set the permissions for the table with:
>>>
>>> GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE
>>> [SchemaName].openjpa_sequence_table TO [UserName];
>>>
>>> *NOTE: This Sequence Table was autogenerated by openJPA - you name
>>> might be different!
>>>
>>>
>>> John
>>>
>>>
AW: Postgres sequence: current transaction is aborted
Posted by Boblitz John <Jo...@BERTSCHI.com>.
Hi Keven,
Oh.
The same GRANT will work though - no need to play with ownership.
Cheers!
John
> -----Ursprüngliche Nachricht-----
> Von: Kevin Sutter [mailto:kwsutter@gmail.com]
> Gesendet: Mittwoch, 20. Juni 2012 15:32
> An: users@openjpa.apache.org
> Betreff: Re: Postgres sequence: current transaction is aborted
>
> Hi John,
> In this case, Marco was using a database Sequence, not the
> OpenJPA sequence table. There was an issue with having
> permissions to alter the Sequence with Postgres. Just wanted
> to clarify. Thanks!
>
> Kevin
>
> On Wed, Jun 20, 2012 at 12:57 AM, Boblitz John
> <Jo...@bertschi.com>wrote:
>
> > You can set the permissions for the table with:
> >
> > GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE
> > [SchemaName].openjpa_sequence_table TO [UserName];
> >
> > *NOTE: This Sequence Table was autogenerated by openJPA - you name
> > might be different!
> >
> >
> > John
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Marco de Booij [mailto:mdebooy@scarlet.be]
> > > Gesendet: Dienstag, 19. Juni 2012 22:08
> > > An: users@openjpa.apache.org
> > > Betreff: Re: Postgres sequence: current transaction is aborted
> > >
> > > Hello Kevin,
> > >
> > > Thanks for the help. Your work around solved my problem.
> I made my
> > > application user the owner of the sequence and I was able
> to insert
> > > my rows. I could not find how/if I could grant the rights.
> > >
> > > I hope that the 'final' solution works without this ALTER
> SEQUENCE
> > > statement. I personally do not like to use the owner of
> objects in a
> > > datasource. Applications should not be allowed to change database
> > > objects. They only should change data. However if you do
> not give a
> > > SQL script with your application then you need to have openJPA
> > > creating the objects :-)
> > >
> > > There is 1 big disadvantage. With increment of 50 you get
> big holes
> > > in your primary keys. My first key was 53 (the current
> value was 3
> > > before I
> > > started) and after I restarted Tomee and inserted another row the
> > > primary key went from 171 to 203. I set the
> allocationSize to 2 for
> > > smaller holes.
> > >
> > > Regards,
> > >
> > > Marco
> > >
> > > Op 19-06-12 00:06, Kevin Sutter schreef:
> > > > Hi Marco,
> > > > The trace from Postgres is helping to understand the issue.
> > > I think
> > > > the basic problem is that the application doesn't have proper
> > > > permissions to update (alter) the sequence:
> > > >
> > > > 2012-06-18 20:17:28 CEST ERROR: must be owner of relation
> > > > seq_i18n_codes
> > > > 2012-06-18 20:17:28 CEST STATEMENT: ALTER SEQUENCE
> > > > DOOS.SEQ_I18N_CODES INCREMENT BY 50
> > > >
> > > > If the permissions for this sequence can be set to
> allow for this
> > > > "alter sequence..." statement, then you would be in the clear.
> > > > Unfortunately, I am not a Postgres expert, so I don't know
> > > the magic
> > > > incantation to allow for this. But, if this can be figured
> > > out then
> > > > you would be in much better shape.
> > > >
> > > > It looks like this whole issue is coming about due to
> the changes
> > > > introduced with OpenJPA-1376 and OpenJPA-2069. The
> > > configuration of
> > > > sequences was not properly implemented in the first place. The
> > > > parameters were not properly applied to the sequence
> creation. As
> > > > part of that fix, it was determined to always execute
> the "alter
> > > > sequence.." statement to ensure that the sequence in
> the database
> > > > matched the expectations of the sequence definition.
> This "alter
> > > > sequence.." statement must be acceptable to all of the other
> > > > databases, just not Postgres due to the permissions thing.
> > > >
> > > > As a side issue... Your idea of setting the
> allocationSize to 1
> > > > should have been a good workaround. Unfortunately, the
> > > generation of
> > > > the "alter sequence.." statement has a problem -- as you have
> > > > discovered. Since the allocationSize is not greater than
> > > 1, we quit
> > > > generating the "alter sequence.." statement and we end
> up with the
> > > > syntax error as you reported below (OpenJPA-2196). And,
> > > since we blindly issue the "alter sequence.."
> > > > statement, there is not a way to disable the generation and
> > > execution
> > > > of this statement. So, two issues surfaced with that
> workaround...
> > > >
> > > > All of this is saying that I don't have a quick answer for
> > > you... If
> > > > the owner permission thing can be figured out for
> Postgres, that's
> > > > going to be the quickest workaround. Otherwise, it looks
> > > like we have
> > > > 2 or 3 problems that need a JIRA resolution.
> > > >
> > > > Kevin
> > > >
> > > > On Mon, Jun 18, 2012 at 3:17 PM, Marco de
> > > Booij<md...@scarlet.be> wrote:
> > > >
> > >
> > >
> >
>
Re: Postgres sequence: current transaction is aborted
Posted by Kevin Sutter <kw...@gmail.com>.
Hi John,
In this case, Marco was using a database Sequence, not the OpenJPA sequence
table. There was an issue with having permissions to alter the Sequence
with Postgres. Just wanted to clarify. Thanks!
Kevin
On Wed, Jun 20, 2012 at 12:57 AM, Boblitz John <Jo...@bertschi.com>wrote:
> You can set the permissions for the table with:
>
> GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE
> [SchemaName].openjpa_sequence_table TO [UserName];
>
> *NOTE: This Sequence Table was autogenerated by openJPA - you name might
> be different!
>
>
> John
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Marco de Booij [mailto:mdebooy@scarlet.be]
> > Gesendet: Dienstag, 19. Juni 2012 22:08
> > An: users@openjpa.apache.org
> > Betreff: Re: Postgres sequence: current transaction is aborted
> >
> > Hello Kevin,
> >
> > Thanks for the help. Your work around solved my problem. I
> > made my application user the owner of the sequence and I was
> > able to insert my rows. I could not find how/if I could grant
> > the rights.
> >
> > I hope that the 'final' solution works without this ALTER
> > SEQUENCE statement. I personally do not like to use the owner
> > of objects in a datasource. Applications should not be
> > allowed to change database objects. They only should change
> > data. However if you do not give a SQL script with your
> > application then you need to have openJPA creating the objects :-)
> >
> > There is 1 big disadvantage. With increment of 50 you get big
> > holes in your primary keys. My first key was 53 (the current
> > value was 3 before I
> > started) and after I restarted Tomee and inserted another row
> > the primary key went from 171 to 203. I set the
> > allocationSize to 2 for smaller holes.
> >
> > Regards,
> >
> > Marco
> >
> > Op 19-06-12 00:06, Kevin Sutter schreef:
> > > Hi Marco,
> > > The trace from Postgres is helping to understand the issue.
> > I think
> > > the basic problem is that the application doesn't have proper
> > > permissions to update (alter) the sequence:
> > >
> > > 2012-06-18 20:17:28 CEST ERROR: must be owner of relation
> > > seq_i18n_codes
> > > 2012-06-18 20:17:28 CEST STATEMENT: ALTER SEQUENCE
> > > DOOS.SEQ_I18N_CODES INCREMENT BY 50
> > >
> > > If the permissions for this sequence can be set to allow for this
> > > "alter sequence..." statement, then you would be in the clear.
> > > Unfortunately, I am not a Postgres expert, so I don't know
> > the magic
> > > incantation to allow for this. But, if this can be figured
> > out then
> > > you would be in much better shape.
> > >
> > > It looks like this whole issue is coming about due to the changes
> > > introduced with OpenJPA-1376 and OpenJPA-2069. The
> > configuration of
> > > sequences was not properly implemented in the first place. The
> > > parameters were not properly applied to the sequence creation. As
> > > part of that fix, it was determined to always execute the "alter
> > > sequence.." statement to ensure that the sequence in the database
> > > matched the expectations of the sequence definition. This "alter
> > > sequence.." statement must be acceptable to all of the other
> > > databases, just not Postgres due to the permissions thing.
> > >
> > > As a side issue... Your idea of setting the allocationSize to 1
> > > should have been a good workaround. Unfortunately, the
> > generation of
> > > the "alter sequence.." statement has a problem -- as you have
> > > discovered. Since the allocationSize is not greater than
> > 1, we quit
> > > generating the "alter sequence.." statement and we end up with the
> > > syntax error as you reported below (OpenJPA-2196). And,
> > since we blindly issue the "alter sequence.."
> > > statement, there is not a way to disable the generation and
> > execution
> > > of this statement. So, two issues surfaced with that workaround...
> > >
> > > All of this is saying that I don't have a quick answer for
> > you... If
> > > the owner permission thing can be figured out for Postgres, that's
> > > going to be the quickest workaround. Otherwise, it looks
> > like we have
> > > 2 or 3 problems that need a JIRA resolution.
> > >
> > > Kevin
> > >
> > > On Mon, Jun 18, 2012 at 3:17 PM, Marco de
> > Booij<md...@scarlet.be> wrote:
> > >
> >
> >
>
AW: Postgres sequence: current transaction is aborted
Posted by Boblitz John <Jo...@BERTSCHI.com>.
You can set the permissions for the table with:
GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE [SchemaName].openjpa_sequence_table TO [UserName];
*NOTE: This Sequence Table was autogenerated by openJPA - you name might be different!
John
> -----Ursprüngliche Nachricht-----
> Von: Marco de Booij [mailto:mdebooy@scarlet.be]
> Gesendet: Dienstag, 19. Juni 2012 22:08
> An: users@openjpa.apache.org
> Betreff: Re: Postgres sequence: current transaction is aborted
>
> Hello Kevin,
>
> Thanks for the help. Your work around solved my problem. I
> made my application user the owner of the sequence and I was
> able to insert my rows. I could not find how/if I could grant
> the rights.
>
> I hope that the 'final' solution works without this ALTER
> SEQUENCE statement. I personally do not like to use the owner
> of objects in a datasource. Applications should not be
> allowed to change database objects. They only should change
> data. However if you do not give a SQL script with your
> application then you need to have openJPA creating the objects :-)
>
> There is 1 big disadvantage. With increment of 50 you get big
> holes in your primary keys. My first key was 53 (the current
> value was 3 before I
> started) and after I restarted Tomee and inserted another row
> the primary key went from 171 to 203. I set the
> allocationSize to 2 for smaller holes.
>
> Regards,
>
> Marco
>
> Op 19-06-12 00:06, Kevin Sutter schreef:
> > Hi Marco,
> > The trace from Postgres is helping to understand the issue.
> I think
> > the basic problem is that the application doesn't have proper
> > permissions to update (alter) the sequence:
> >
> > 2012-06-18 20:17:28 CEST ERROR: must be owner of relation
> > seq_i18n_codes
> > 2012-06-18 20:17:28 CEST STATEMENT: ALTER SEQUENCE
> > DOOS.SEQ_I18N_CODES INCREMENT BY 50
> >
> > If the permissions for this sequence can be set to allow for this
> > "alter sequence..." statement, then you would be in the clear.
> > Unfortunately, I am not a Postgres expert, so I don't know
> the magic
> > incantation to allow for this. But, if this can be figured
> out then
> > you would be in much better shape.
> >
> > It looks like this whole issue is coming about due to the changes
> > introduced with OpenJPA-1376 and OpenJPA-2069. The
> configuration of
> > sequences was not properly implemented in the first place. The
> > parameters were not properly applied to the sequence creation. As
> > part of that fix, it was determined to always execute the "alter
> > sequence.." statement to ensure that the sequence in the database
> > matched the expectations of the sequence definition. This "alter
> > sequence.." statement must be acceptable to all of the other
> > databases, just not Postgres due to the permissions thing.
> >
> > As a side issue... Your idea of setting the allocationSize to 1
> > should have been a good workaround. Unfortunately, the
> generation of
> > the "alter sequence.." statement has a problem -- as you have
> > discovered. Since the allocationSize is not greater than
> 1, we quit
> > generating the "alter sequence.." statement and we end up with the
> > syntax error as you reported below (OpenJPA-2196). And,
> since we blindly issue the "alter sequence.."
> > statement, there is not a way to disable the generation and
> execution
> > of this statement. So, two issues surfaced with that workaround...
> >
> > All of this is saying that I don't have a quick answer for
> you... If
> > the owner permission thing can be figured out for Postgres, that's
> > going to be the quickest workaround. Otherwise, it looks
> like we have
> > 2 or 3 problems that need a JIRA resolution.
> >
> > Kevin
> >
> > On Mon, Jun 18, 2012 at 3:17 PM, Marco de
> Booij<md...@scarlet.be> wrote:
> >
>
>
Re: Postgres sequence: current transaction is aborted
Posted by Marco de Booij <md...@scarlet.be>.
Hello Kevin,
Thanks for the help. Your work around solved my problem. I made my
application user the owner of the sequence and I was able to insert my
rows. I could not find how/if I could grant the rights.
I hope that the 'final' solution works without this ALTER SEQUENCE
statement. I personally do not like to use the owner of objects in a
datasource. Applications should not be allowed to change database
objects. They only should change data. However if you do not give a SQL
script with your application then you need to have openJPA creating the
objects :-)
There is 1 big disadvantage. With increment of 50 you get big holes in
your primary keys. My first key was 53 (the current value was 3 before I
started) and after I restarted Tomee and inserted another row the
primary key went from 171 to 203. I set the allocationSize to 2 for
smaller holes.
Regards,
Marco
Op 19-06-12 00:06, Kevin Sutter schreef:
> Hi Marco,
> The trace from Postgres is helping to understand the issue. I think the
> basic problem is that the application doesn't have proper permissions to
> update (alter) the sequence:
>
> 2012-06-18 20:17:28 CEST ERROR: must be owner of relation seq_i18n_codes
> 2012-06-18 20:17:28 CEST STATEMENT: ALTER SEQUENCE DOOS.SEQ_I18N_CODES
> INCREMENT BY 50
>
> If the permissions for this sequence can be set to allow for this "alter
> sequence..." statement, then you would be in the clear. Unfortunately, I
> am not a Postgres expert, so I don't know the magic incantation to allow
> for this. But, if this can be figured out then you would be in much better
> shape.
>
> It looks like this whole issue is coming about due to the changes
> introduced with OpenJPA-1376 and OpenJPA-2069. The configuration of
> sequences was not properly implemented in the first place. The parameters
> were not properly applied to the sequence creation. As part of that fix,
> it was determined to always execute the "alter sequence.." statement to
> ensure that the sequence in the database matched the expectations of the
> sequence definition. This "alter sequence.." statement must be acceptable
> to all of the other databases, just not Postgres due to the permissions
> thing.
>
> As a side issue... Your idea of setting the allocationSize to 1 should
> have been a good workaround. Unfortunately, the generation of the "alter
> sequence.." statement has a problem -- as you have discovered. Since the
> allocationSize is not greater than 1, we quit generating the "alter
> sequence.." statement and we end up with the syntax error as you reported
> below (OpenJPA-2196). And, since we blindly issue the "alter sequence.."
> statement, there is not a way to disable the generation and execution of
> this statement. So, two issues surfaced with that workaround...
>
> All of this is saying that I don't have a quick answer for you... If the
> owner permission thing can be figured out for Postgres, that's going to be
> the quickest workaround. Otherwise, it looks like we have 2 or 3 problems
> that need a JIRA resolution.
>
> Kevin
>
> On Mon, Jun 18, 2012 at 3:17 PM, Marco de Booij<md...@scarlet.be> wrote:
>
Re: Postgres sequence: current transaction is aborted
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Marco,
The trace from Postgres is helping to understand the issue. I think the
basic problem is that the application doesn't have proper permissions to
update (alter) the sequence:
2012-06-18 20:17:28 CEST ERROR: must be owner of relation seq_i18n_codes
2012-06-18 20:17:28 CEST STATEMENT: ALTER SEQUENCE DOOS.SEQ_I18N_CODES
INCREMENT BY 50
If the permissions for this sequence can be set to allow for this "alter
sequence..." statement, then you would be in the clear. Unfortunately, I
am not a Postgres expert, so I don't know the magic incantation to allow
for this. But, if this can be figured out then you would be in much better
shape.
It looks like this whole issue is coming about due to the changes
introduced with OpenJPA-1376 and OpenJPA-2069. The configuration of
sequences was not properly implemented in the first place. The parameters
were not properly applied to the sequence creation. As part of that fix,
it was determined to always execute the "alter sequence.." statement to
ensure that the sequence in the database matched the expectations of the
sequence definition. This "alter sequence.." statement must be acceptable
to all of the other databases, just not Postgres due to the permissions
thing.
As a side issue... Your idea of setting the allocationSize to 1 should
have been a good workaround. Unfortunately, the generation of the "alter
sequence.." statement has a problem -- as you have discovered. Since the
allocationSize is not greater than 1, we quit generating the "alter
sequence.." statement and we end up with the syntax error as you reported
below (OpenJPA-2196). And, since we blindly issue the "alter sequence.."
statement, there is not a way to disable the generation and execution of
this statement. So, two issues surfaced with that workaround...
All of this is saying that I don't have a quick answer for you... If the
owner permission thing can be figured out for Postgres, that's going to be
the quickest workaround. Otherwise, it looks like we have 2 or 3 problems
that need a JIRA resolution.
Kevin
On Mon, Jun 18, 2012 at 3:17 PM, Marco de Booij <md...@scarlet.be> wrote:
> I searched further. Somebody mentioned to add allocationSize=1 to the
> @SequenceGenerator but this did not solve the problem. I now get a simple
> alter sequence statement that looks like the problem (OPENJPA-2196) Create
> Sequence Postgres 9.1. Hope that this helps you a bit more.
>
> 2012-06-18 22:16:18 CEST LOG: execute S_2: COMMIT
> 2012-06-18 22:16:18 CEST LOG: execute S_1: BEGIN
> 2012-06-18 22:16:18 CEST ERROR: syntax error at end of input at character
> 35
> 2012-06-18 22:16:18 CEST STATEMENT: ALTER SEQUENCE DOOS.SEQ_I18N_CODES
> 2012-06-18 22:16:18 CEST ERROR: current transaction is aborted, commands
> ignored until end of transaction block
> 2012-06-18 22:16:18 CEST STATEMENT: SELECT NEXTVAL('DOOS.SEQ_I18N_CODES')
> 2012-06-18 22:16:18 CEST LOG: execute S_3: ROLLBACK
>
> Regards,
>
> Marco
>
>
> Op 18-06-12 15:28, Kevin Sutter schreef:
>
>> Hi Marco,
>>
>> That 25P02 state from Postgres is so nebulous... It really doesn't help
>> explain the problem that Postgres is complaining about... We've had some
>> recent activity on the OpenJPA mailing lists related to Postgres and
>> Sequences. It seems that we have varying degrees of success with
>> different
>> customers.
>>
>> Can you post the complete stack when you receive this error? Have you
>> searched the log for other problems leading up to this Error? Have you
>> tried turning on Trace for both OpenJPA and Postgres? No guarantees, but
>> Trace might shed some light on the issue.
>>
>> The Junit bucket for OpenJPA has various tests relating to Id generation
>> and sequences, and these seem to work with Postgres... So, we might need
>> some assistance with narrowing in the test and debug setup to help
>> reproduce the problem and eventually solve it.
>>
>> Thanks,
>> Kevin
>>
>>
>
Re: Postgres sequence: current transaction is aborted
Posted by Marco de Booij <md...@scarlet.be>.
I searched further. Somebody mentioned to add allocationSize=1 to the
@SequenceGenerator but this did not solve the problem. I now get a
simple alter sequence statement that looks like the problem
(OPENJPA-2196) Create Sequence Postgres 9.1. Hope that this helps you a
bit more.
2012-06-18 22:16:18 CEST LOG: execute S_2: COMMIT
2012-06-18 22:16:18 CEST LOG: execute S_1: BEGIN
2012-06-18 22:16:18 CEST ERROR: syntax error at end of input at
character 35
2012-06-18 22:16:18 CEST STATEMENT: ALTER SEQUENCE DOOS.SEQ_I18N_CODES
2012-06-18 22:16:18 CEST ERROR: current transaction is aborted,
commands ignored until end of transaction block
2012-06-18 22:16:18 CEST STATEMENT: SELECT NEXTVAL('DOOS.SEQ_I18N_CODES')
2012-06-18 22:16:18 CEST LOG: execute S_3: ROLLBACK
Regards,
Marco
Op 18-06-12 15:28, Kevin Sutter schreef:
> Hi Marco,
> That 25P02 state from Postgres is so nebulous... It really doesn't help
> explain the problem that Postgres is complaining about... We've had some
> recent activity on the OpenJPA mailing lists related to Postgres and
> Sequences. It seems that we have varying degrees of success with different
> customers.
>
> Can you post the complete stack when you receive this error? Have you
> searched the log for other problems leading up to this Error? Have you
> tried turning on Trace for both OpenJPA and Postgres? No guarantees, but
> Trace might shed some light on the issue.
>
> The Junit bucket for OpenJPA has various tests relating to Id generation
> and sequences, and these seem to work with Postgres... So, we might need
> some assistance with narrowing in the test and debug setup to help
> reproduce the problem and eventually solve it.
>
> Thanks,
> Kevin
>
Re: Postgres sequence: current transaction is aborted
Posted by Marco de Booij <md...@scarlet.be>.
Hello Kevin,
I hope that it is not an error due to my lack of knowledge/experience. I
will download the jUnit bucket.
For the openJPA logs I need to figure out where to configure this in
Tomee. I never used JULI :(
What I see in the postgres log file puzzles me:
2012-06-18 20:17:28 CEST ERROR: must be owner of relation seq_i18n_codes
2012-06-18 20:17:28 CEST STATEMENT: ALTER SEQUENCE DOOS.SEQ_I18N_CODES
INCREMENT BY 50
2012-06-18 20:17:28 CEST ERROR: current transaction is aborted,
commands ignored until end of transaction block
2012-06-18 20:17:28 CEST STATEMENT: SELECT NEXTVAL('DOOS.SEQ_I18N_CODES')
I do not understand where the alter statement comes from. Can this be
the reason for the error? The user in the datasource has rights to the
sequence through a role. The sequence is created like:
CREATE SEQUENCE doos.seq_i18n_codes
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 1
CACHE 1;
The stack trace is the easiest part:
18-jun-2012 20:17:28 org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [Faces Servlet] in context with
path [/doos-web] threw exception [javax.el.ELException:
DoosRuntimeException (
eu.debooy.doosutils.errorhandling.exception.TechnicalException: ERROR:
current transaction is aborted, commands ignored until end of
transaction block {prepstmnt 1825309558 SELECT
NEXTVAL('DOOS.SEQ_I18N_CODES')} [code=0, state=25P02] layer =
DoosLayer ( PERSISTENCE value = N/A ) error = DoosError (
eu.debooy.doosutils.errorhandling.exception.base.DoosError@77cb95b3
code = RUNTIME_EXCEPTION description = RUNTIME_EXCEPTION ) )] with
root cause
org.apache.openjpa.lib.jdbc.ReportingSQLException: ERROR: current
transaction is aborted, commands ignored until end of transaction block
{prepstmnt 1825309558 SELECT NEXTVAL('DOOS.SEQ_I18N_CODES')} [code=0,
state=25P02]
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:247)
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:231)
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$700(LoggingConnectionDecorator.java:72)
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeQuery(LoggingConnectionDecorator.java:1146)
at
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:265)
at
org.apache.openjpa.jdbc.sql.PostgresDictionary$PostgresPreparedStatement.executeQuery(PostgresDictionary.java:1019)
at
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:265)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeQuery(JDBCStoreManager.java:1750)
at
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:255)
at
org.apache.openjpa.jdbc.kernel.NativeJDBCSeq.getSequence(NativeJDBCSeq.java:299)
at
org.apache.openjpa.jdbc.kernel.NativeJDBCSeq.allocateInternal(NativeJDBCSeq.java:223)
at
org.apache.openjpa.jdbc.kernel.NativeJDBCSeq.nextInternal(NativeJDBCSeq.java:197)
at
org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq.next(AbstractJDBCSeq.java:60)
at
org.apache.openjpa.util.ImplHelper.generateValue(ImplHelper.java:160)
at
org.apache.openjpa.util.ImplHelper.generateFieldValue(ImplHelper.java:144)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignField(JDBCStoreManager.java:756)
at
org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:493)
at
org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:469)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignObjectId(JDBCStoreManager.java:740)
at
org.apache.openjpa.kernel.DelegatingStoreManager.assignObjectId(DelegatingStoreManager.java:135)
at
org.apache.openjpa.kernel.StateManagerImpl.assignObjectId(StateManagerImpl.java:612)
at
org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:2977)
at org.apache.openjpa.kernel.PNewState.beforeFlush(PNewState.java:40)
at
org.apache.openjpa.kernel.StateManagerImpl.beforeFlush(StateManagerImpl.java:1054)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2112)
at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2072)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1843)
at
org.apache.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:1045)
at
org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:663)
at
org.apache.openejb.persistence.JtaEntityManager.flush(JtaEntityManager.java:184)
at eu.debooy.doosutils.access.Dao.create(Dao.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:181)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:163)
at
eu.debooy.doosutils.errorhandling.handler.interceptor.PersistenceExceptionHandlerInterceptor.handleException(PersistenceExceptionHandlerInterceptor.java:51)
at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:181)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:163)
at
org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:176)
at
org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:95)
at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:181)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:163)
at
org.apache.openejb.cdi.CdiInterceptor.invoke(CdiInterceptor.java:129)
at
org.apache.openejb.cdi.CdiInterceptor.access$000(CdiInterceptor.java:45)
at org.apache.openejb.cdi.CdiInterceptor$1.call(CdiInterceptor.java:66)
at
org.apache.openejb.cdi.CdiInterceptor.aroundInvoke(CdiInterceptor.java:72)
at sun.reflect.GeneratedMethodAccessor58.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:181)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:163)
at
org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:138)
at
org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:226)
at
org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:178)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:260)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:240)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:91)
at
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:284)
at
eu.debooy.doos.access.I18nCodeDao$LocalBeanProxy.create(eu/debooy/doos/access/I18nCodeDao.java)
at
eu.debooy.doos.business.I18nCodeManager.createI18nCode(I18nCodeManager.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:181)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:163)
at
eu.debooy.doosutils.errorhandling.handler.interceptor.PersistenceExceptionHandlerInterceptor.handleException(PersistenceExceptionHandlerInterceptor.java:51)
at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:181)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:163)
at
org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:176)
at
org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:95)
at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:181)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:163)
at
org.apache.openejb.cdi.CdiInterceptor.invoke(CdiInterceptor.java:129)
at
org.apache.openejb.cdi.CdiInterceptor.access$000(CdiInterceptor.java:45)
at org.apache.openejb.cdi.CdiInterceptor$1.call(CdiInterceptor.java:66)
at
org.apache.openejb.cdi.CdiInterceptor.aroundInvoke(CdiInterceptor.java:72)
at sun.reflect.GeneratedMethodAccessor58.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:181)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:163)
at
org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:138)
at
org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:226)
at
org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:178)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:260)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:240)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:91)
at
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:284)
at
eu.debooy.doos.business.I18nCodeManager$LocalBeanProxy.createI18nCode(eu/debooy/doos/business/I18nCodeManager.java)
at
eu.debooy.doos.component.I18nCodeComponent.insert(I18nCodeComponent.java:93)
at
eu.debooy.doos.web.controller.I18nUploadBean.upload(I18nUploadBean.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.el.parser.AstValue.invoke(AstValue.java:264)
at
org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278)
at
org.apache.myfaces.view.facelets.el.ContextAwareTagMethodExpression.invoke(ContextAwareTagMethodExpression.java:96)
at
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:72)
at javax.faces.component.UICommand.broadcast(UICommand.java:120)
at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1023)
at
javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:286)
at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1360)
at
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752)
at
org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:38)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:44)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Op 18-06-12 15:28, Kevin Sutter schreef:
> Hi Marco,
> That 25P02 state from Postgres is so nebulous... It really doesn't help
> explain the problem that Postgres is complaining about... We've had some
> recent activity on the OpenJPA mailing lists related to Postgres and
> Sequences. It seems that we have varying degrees of success with different
> customers.
>
> Can you post the complete stack when you receive this error? Have you
> searched the log for other problems leading up to this Error? Have you
> tried turning on Trace for both OpenJPA and Postgres? No guarantees, but
> Trace might shed some light on the issue.
>
> The Junit bucket for OpenJPA has various tests relating to Id generation
> and sequences, and these seem to work with Postgres... So, we might need
> some assistance with narrowing in the test and debug setup to help
> reproduce the problem and eventually solve it.
>
> Thanks,
> Kevin
Re: Postgres sequence: current transaction is aborted
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Marco,
That 25P02 state from Postgres is so nebulous... It really doesn't help
explain the problem that Postgres is complaining about... We've had some
recent activity on the OpenJPA mailing lists related to Postgres and
Sequences. It seems that we have varying degrees of success with different
customers.
Can you post the complete stack when you receive this error? Have you
searched the log for other problems leading up to this Error? Have you
tried turning on Trace for both OpenJPA and Postgres? No guarantees, but
Trace might shed some light on the issue.
The Junit bucket for OpenJPA has various tests relating to Id generation
and sequences, and these seem to work with Postgres... So, we might need
some assistance with narrowing in the test and debug setup to help
reproduce the problem and eventually solve it.
Thanks,
Kevin
On Sun, Jun 17, 2012 at 10:17 AM, Marco de Booij <md...@scarlet.be> wrote:
> Hello,
>
> I have been searching on the internet for a solution of 'my' problem:
> ERROR: current transaction is aborted, commands ignored until end of
> transaction block {prepstmnt 253501751 SELECT NEXTVAL('DOOS.SEQ_I18N_CODES')
> **} [code=0, state=25P02]
>
> I found questions on this dating back to 2000 but not clear answer (to me)
> on how to solve it.
>
> What do I have? A class to persist:
> @Entity
> @Table(name="I18N_CODES", schema="DOOS")
> @SequenceGenerator(name="SEQ_**CODE_ID", schema="DOOS",
> sequenceName="SEQ_I18N_CODES")
> public class I18nCodeDto extends Dto
> implements Comparable<I18nCodeDto>, Cloneable {
> @Id
> @GeneratedValue(strategy=**GenerationType.SEQUENCE,
> generator="SEQ_CODE_ID")
> @Column(name="CODE_ID", nullable=false)
> private Long codeId;
> @Column(name="CODE", length=100, nullable=false, unique=true)
> private String code;
>
> @OneToMany(fetch=FetchType.**EAGER)
> @JoinColumn(name="CODE_ID")
> @OrderBy("id.taalKode ASC")
> private List<I18nCodeTekstDto> teksten = new
> ArrayList<I18nCodeTekstDto>();
>
> The class has the getters and setters that are needed. The user that
> connects to the datasource has access to the sequence and the tables. I get
> the error when I try to persist the object.
> i18nCodeComponent.insert(**i18nCode);
>
> The insert ends up in a create method:
> /**
> * Persist de DTO
> *
> * @param dto
> * @return
> * @throws DoosRuntimeException
> * @throws DuplicateObjectException
> */
> public T create(T dto) throws DoosRuntimeException,
> DuplicateObjectException {
> if (getEntityManager().contains(**dto)) {
> throw new DuplicateObjectException(**DoosLayer.PERSISTENCE, dto,
> "bestaat reeds");
> }
>
> getEntityManager().persist(**dto);
> getEntityManager().flush();
> getEntityManager().refresh(**dto);
>
> return dto;
> }
>
> My question is how I solve this problem?
>
> I tried it with Postgres 8.4 and 9.1 with the jdbc drivers for this
> version and it failed in both cases. The code worked fine when I used MySQL
> with auto-increment (with the correct @GeneratedValue :-) ) and with Oracle
> Sequence + Hibernate it also works.
>
> I use apache-tomee-plus-1.0.0.
>
> Regards,
>
> Marco
>
>