You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig Russell <Cr...@Sun.COM> on 2005/09/15 18:56:47 UTC
Specification issues with Sequence
Hi Andy,
I'm reading the description of the three strategies again and I can't
figure it out. I think I understand nontransactional and contiguous,
but don't understand noncontiguous.
Obtaining a sequence number within the transaction implies an update
of the sequence so that no other transaction gets the same number.
This sounds like exclusive use of the sequence is required.
I agree with you that a no-args construction static method
newInstance is not sufficient to the task. I think we need a
newInstance method that at least supplies the name and strategy. So
I'd propose newInstance(String name, String strategy). The reason for
String strategy is that the xml is not exhaustive. It just provides
values that are "standard".
The xml and the text are in conflict. The text says "The strategy
attribute specifies the strategy for generating sequence numbers.
Standard values are...". This implies that the strategy is not
restricted to these three. But the xml says <!ATTLIST sequence
strategy (nontransactional|contiguous|noncontiguous) #REQUIRED> which
implies that only these three can be used.
I also don't know how the factory implementation can implement the
different strategies without some help from the JDOImplHelper. I
suspect that there is some design work needed here.
Other experts,
Any insights here?
Craig
On Sep 15, 2005, at 1:12 AM, Andy Jefferson wrote:
>> *** For factory sequences (not defined in the database) is the API
>> sufficient to use the sequence in the three modes: nontransactional,
>> contiguous, and noncontiguous? ***
>>
>
> Well, the implementation has to call factory.newInstance() to
> create the
> sequence, but has no way of telling the factory whether it wants a
> contiguous, noncontiguous, or nontransactional sequence.
>
> Really depends whether the users sequence that is created by the
> factory will
> typically be able to operate in all 3 strategies. I would guess
> that most
> sequences would support one of the 3 strategies, so by saying that
> they want
> to use a particular factory, then they are implicitly electing the
> strategy
> that will be used.
>
> If it is really necessary to allow a factory to create a sequence
> in any of
> the 3 strategies then we could add a requirement on the factory of
> having a
> static newInstance(int strategy) method, and the "strategy" value
> specified
> in the metadata could be passed in. If the metadata has no value
> for strategy
> then the newInstance() method is called.
>
>
>
>> *** Does Derby support sequences? ***
>>
>
> No.
> DB2, PostgreSQL, Oracle, Firebird, SAPDB, McKoi and maybe some
> others do.
> The JDO impl can clearly generate a sequence using other means
> where there is
> no native RDBMS support.
>
>
> --
> Andy
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Specification issues with Sequence
Posted by Craig Russell <Cr...@Sun.COM>.
Hi Erik,
So both transactional methods exclusively lock the sequence,
essentially single-threading it. Multiple transactions using the same
sequence for any purpose will be serialized.
Craig
On Sep 15, 2005, at 12:09 PM, erik@jpox.org wrote:
> Craig,
>
> Noncontiguous sequence will usually occur when the jdo impl or
> database
> reserves N number of identifiers out of the JDO transaction but
> does not
> use all of them. The second case occurs when the increment value is
> greater than one.
>
> Erik Bengtson
> -----Original Message-----
> From: Craig Russell [mailto:Craig.Russell@Sun.COM]
> Sent: Thursday, September 15, 2005 6:57 PM
> To: jdo-dev@db.apache.org; JDO Expert Group
> Subject: Specification issues with Sequence
>
> Hi Andy,
>
> I'm reading the description of the three strategies again and I can't
> figure it out. I think I understand nontransactional and
> contiguous, but
> don't understand noncontiguous.
>
> Obtaining a sequence number within the transaction implies an
> update of
> the sequence so that no other transaction gets the same number. This
> sounds like exclusive use of the sequence is required.
>
> I agree with you that a no-args construction static method newInstance
> is not sufficient to the task. I think we need a newInstance method
> that
> at least supplies the name and strategy. So I'd propose
> newInstance(String name, String strategy). The reason for String
> strategy is that the xml is not exhaustive. It just provides values
> that
> are "standard".
>
> The xml and the text are in conflict. The text says "The strategy
> attribute specifies the strategy for generating sequence numbers.
> Standard values are...". This implies that the strategy is not
> restricted to these three. But the xml says <!ATTLIST sequence
> strategy
> (nontransactional|contiguous|noncontiguous) #REQUIRED> which implies
> that only these three can be used.
>
> I also don't know how the factory implementation can implement the
> different strategies without some help from the JDOImplHelper. I
> suspect
> that there is some design work needed here.
>
> Other experts,
>
> Any insights here?
>
> Craig
>
> On Sep 15, 2005, at 1:12 AM, Andy Jefferson wrote:
>
>
>
> *** For factory sequences (not defined in the database) is the API
> sufficient to use the sequence in the three modes: nontransactional,
> contiguous, and noncontiguous? ***
>
>
> Well, the implementation has to call factory.newInstance() to
> create the
>
> sequence, but has no way of telling the factory whether it wants a
> contiguous, noncontiguous, or nontransactional sequence.
>
> Really depends whether the users sequence that is created by the
> factory
> will
> typically be able to operate in all 3 strategies. I would guess that
> most
> sequences would support one of the 3 strategies, so by saying that
> they
> want
> to use a particular factory, then they are implicitly electing the
> strategy
> that will be used.
>
> If it is really necessary to allow a factory to create a sequence
> in any
> of
> the 3 strategies then we could add a requirement on the factory of
> having a
> static newInstance(int strategy) method, and the "strategy" value
> specified
> in the metadata could be passed in. If the metadata has no value for
> strategy
> then the newInstance() method is called.
>
>
>
>
>
> *** Does Derby support sequences? ***
>
>
> No.
> DB2, PostgreSQL, Oracle, Firebird, SAPDB, McKoi and maybe some others
> do.
> The JDO impl can clearly generate a sequence using other means where
> there is
> no native RDBMS support.
>
>
> --
> Andy
>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
RE: Specification issues with Sequence
Posted by er...@jpox.org.
Craig,
Noncontiguous sequence will usually occur when the jdo impl or database
reserves N number of identifiers out of the JDO transaction but does not
use all of them. The second case occurs when the increment value is
greater than one.
Erik Bengtson
-----Original Message-----
From: Craig Russell [mailto:Craig.Russell@Sun.COM]
Sent: Thursday, September 15, 2005 6:57 PM
To: jdo-dev@db.apache.org; JDO Expert Group
Subject: Specification issues with Sequence
Hi Andy,
I'm reading the description of the three strategies again and I can't
figure it out. I think I understand nontransactional and contiguous, but
don't understand noncontiguous.
Obtaining a sequence number within the transaction implies an update of
the sequence so that no other transaction gets the same number. This
sounds like exclusive use of the sequence is required.
I agree with you that a no-args construction static method newInstance
is not sufficient to the task. I think we need a newInstance method that
at least supplies the name and strategy. So I'd propose
newInstance(String name, String strategy). The reason for String
strategy is that the xml is not exhaustive. It just provides values that
are "standard".
The xml and the text are in conflict. The text says "The strategy
attribute specifies the strategy for generating sequence numbers.
Standard values are...". This implies that the strategy is not
restricted to these three. But the xml says <!ATTLIST sequence strategy
(nontransactional|contiguous|noncontiguous) #REQUIRED> which implies
that only these three can be used.
I also don't know how the factory implementation can implement the
different strategies without some help from the JDOImplHelper. I suspect
that there is some design work needed here.
Other experts,
Any insights here?
Craig
On Sep 15, 2005, at 1:12 AM, Andy Jefferson wrote:
*** For factory sequences (not defined in the database) is the API
sufficient to use the sequence in the three modes: nontransactional,
contiguous, and noncontiguous? ***
Well, the implementation has to call factory.newInstance() to create the
sequence, but has no way of telling the factory whether it wants a
contiguous, noncontiguous, or nontransactional sequence.
Really depends whether the users sequence that is created by the factory
will
typically be able to operate in all 3 strategies. I would guess that
most
sequences would support one of the 3 strategies, so by saying that they
want
to use a particular factory, then they are implicitly electing the
strategy
that will be used.
If it is really necessary to allow a factory to create a sequence in any
of
the 3 strategies then we could add a requirement on the factory of
having a
static newInstance(int strategy) method, and the "strategy" value
specified
in the metadata could be passed in. If the metadata has no value for
strategy
then the newInstance() method is called.
*** Does Derby support sequences? ***
No.
DB2, PostgreSQL, Oracle, Firebird, SAPDB, McKoi and maybe some others
do.
The JDO impl can clearly generate a sequence using other means where
there is
no native RDBMS support.
--
Andy
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!