posledni automaticky generovany id a prenositelnost

[Karel Zak]

On Tue, Aug 10, 2004 at 11:19:12AM +0200, Pavel Janoušek wrote:
> 	Kdyz uz jste s tim zacali...
> 
> > -----Original Message-----
> > From: Jan Serak [mailto:sherry na pikebo.cz] 
> > p := nextval(seq); 	-- v p je 14	
> > p := currval(seq);	-- v p je 14
> > 
> > 					x := nextval(seq); -- x=15
> > 					x := currval(seq); -- x=15
> 
>  Jelikoz  neco  o soubezich  vim,  chci  se  optat, zda-li  je  reseno
>  (predpokladam, ze ano  a to zrejme zamkem a  mozna jeste robustnejsim
>  mechanismem  aby nedochazelo  ani ke  starnuti (starving))  to, ze  p
>  :=  nextval(seq)  v  jednom  okamziku  vyvolaji  dve  a  vice  vlaken
>  aplikace/serveru  - jde  mi  o  to, ze  mame  neco  jako CPU  quantum
>  a  serializaci   a  v   prubehu  interniho  zpracovani   je  procesor
>  odejmut. Takze je tato operace  opravdu definovana jako atomicka nebo
>  se  tak definuje  (napr.  proto, ze  je to  logicke)  a pripadne,  co
>  viceprocesorovy stroj?
>
>  Ptam se  na to  prave s  ohledem na  to, ze  sequence jsou  VYJMUTY z
>  transakci, nemaji isolation level (pokud  ano, jaky?) a vubec prace s
>  nimi vyzaduje trochu jiny pristup/znalosti...

 Sequence  je  tabulka   a  naprosto  stejne  jako  s   tabulkou  s  tim
 zachazi  jen ten  kod je  trosku samostatny  a "hubenejsi"  a nepouziva
 vsechnu  infrastrukturu  jako  u  beznych  tabulek. Zjednodusene  se  v
 "AccessShareLock"  otevre  tabulka  sequence a  nasledne  zamkne  prvni
 buffer  (block)  tabulky  jako  BUFFER_LOCK_EXCLUSIVE,  precte  zaznam,
 modifikuje  a  pak zase  odemkne  (+  jeste  nejake veci  ohledne  logu
 apod). To  je  vse. Pokdu  nekomu  vykonostne  prekazi  ten  lock  muze
 pouzivat cached  sequence, kdy  si session  "alokuje" pro  sebe nekolik
 cisel najednou a pak je nextval() postupne pouziva.

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/