I don't know if that's explicitly defined in the spec, but even if it
wasn't I wouldn't be happy as a user to see an exception for such a
commonly used feature.

Clearly when such an ID is requested we need to invoke the server out of
the batching / transaction context, which might be a suboptimal strategy
but exactly what the user is asking for:theyr choice of they want to
tradeoff simplicity for performance.

Also to keep in mind for the Infinispan case the current approach is very
slow but now that we've upgraded to latest wildfly there's a new feature
could use to optimise for this: COUNTER protocol in JGroups combined with
FORK channels.

Sanne
On 20 Jan 2014 16:42, "Gunnar Morling" <gun...@hibernate.org> wrote:

> Ah, is that specified somewhere? I couldn't find anything in the spec from
> a quick look.
>
>
> 2014/1/20 Emmanuel Bernard <emman...@hibernate.org>
>
> > The problem is that in JPA, IDENTITY returns a long, not a UUID.
> >
> > On Mon 2014-01-20 12:23, Gunnar Morling wrote:
> > > Hi,
> > >
> > > While reviewing the PR for batch operations in OGM [1], I took some
> time
> > to
> > > better understand OGM's approaches for id generation.
> > >
> > > Now I'm wondering about how GenerationType.IDENTITY is implemented. The
> > > corresponding generator (OgmIdentityGenerator) just delegates to a
> > > table-based strategy, so an id is always pre-allocated and then passed
> > into
> > > the dialect when creating a tuple.
> > >
> > > I think it would be nice to have proper support for server-generated
> ids,
> > > in particular since some stores return the inserted id directly from
> the
> > > insert operation, i.e. without requiring another read.
> > >
> > > For the time being, as the current implementation doesn't really adhere
> > to
> > > the semantics of GenerationType.IDENTITY, should we raise an error when
> > > using it instead of silently using another strategy?
> > >
> > > Thoughts?
> > >
> > > --Gunnar
> > >
> > > [1] https://hibernate.atlassian.net/browse/OGM-175
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Reply via email to