Zdravim,
uvediem jeden prakticky priklad kde som vyuzil List<ConnectionImpl> v
ramci ManagedConnection.
Kedysi som sa rozhodol implementovat jca pre ldap, pretoze standardny
javax.naming.* bol nekontrolovatelny a bolo treba dosledne riadit
pristup z aplikacneho servera do ldap-u ktory mal len obmedzeny pocet
spojeni.
Oproti standardnej implementacii ako je to napr. pri db connectoch kde
je vztah managedconnection a connectionimpl takmer vzdy 1:1 tu bolo
nutne riesit napr. problem toho ze javax.naming.directory.DirContext (co
bol inteface pre moj DirContextImpl) ma podla specifikacie vela metod
(napr. createsubcontext, geschema, .. ) ktore vytvaraju dalsi DirContext.
Avsak v case takehoto volania (volana je uz iba trieda DirContextImpl -
nie je dosah na manipulaciu s poolom v managedirconextfactory) zrazu
mohol vzniknut vztah N(ConnectionImpl) ku 1 (ManagedConnection) s tym ze
v pripade zatvorenia "master" DirContextu sa zatvorili aj vsetky
odvodene contexty a master spojenie sa vratilo do poolu.
Norbert Krankilla wrote / napísal(a):
Aj ja prajem dobry den.
Dakujem za zakladne vysvetlenie. Tomuto fungovaniu rozumiem, je to
dost dobre viditelne i vo vygooglenych prikladoch. Ako sa ziskava
ConnectionManager od aplikacneho serveru alebo ako sa vybera
ManagedConnection z connection poolu pomocou matchManagedConnection,
to je mi jasne.
Problem mam ale s /"tajomnym carovanim"/ mezi ConnectionImpl a
ManagedConnection. Tam prave vidim priestor na programatorsku
kreativitu, vysledkom coho sa tradicne jednoducha vec zapletie do
spletenca navzajom nekompatibilnych examplov, kde miesto popisku
/"Let's have a strategy and it's implementation"/ je len /"This is how
you write your RA"/, a clovek ma potom z toho gulas.
Niekde napriklad v ramci ManagedConnection spravuju
List<ConnectionImpl>, alebo sa rozdielne handluju ConnectionEventy.
Je mozne nejak popisat tu myslienku za tym, pripadne uviest nejake 2
strategie na porovnanie?
Este raz dakujem a prajem prijemny piatok.
N.K.
-----Original Message-----
*From*: Zdenek Tronicek <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
*Reply-To*: Java <[email protected]
<mailto:[EMAIL PROTECTED]>>
*To*: [email protected] <mailto:[email protected]>
*Subject*: Re: OutBound J2EE Resource Adapter
*Date*: Fri, 25 Jul 2008 09:17:29 +0200
Dobry den,
podobne jako u databazovych spojeni udrzuje aplikacni server pool
otevrenych spojeni. Spojeni v poolu jsou typu ManagedConnection.
ManagedConnection tedy reprezentuje fyzicke spojeni.
Aplikace, ktera chce toto spojeni pouzivat, nejprve ziska od
aplikaceniho serveru objekt typu ConnectionFactory (pomoci dependency
injection nebo z JNDI) a pote od nej objekt typu Connection.
Connection je interface a ConnectionImpl je trida, ktera jej
implementuje. Objekt ziskany z ConnectionFactory bude typu
ConnectionImpl a reprezentuje spojeni (obsahuje odkaz na
ManagedConnection).
Proc je to delano takto "komplikovane"? Protoze kdyz aplikace zavola
Connection.close(), nesmi dojit k zavreni fyzickeho spojeni (spojeni
putuje do poolu) a po zavolani Connection.close() uz spojeni nesmi byt
pro aplikaci dostupne, protoze je v poolu a muze byt prideleno nekomu
jinemu.
Z.T.
Tento e-mail je urcen pouze pro jeho adresata/adresaty a muze
obsahovat duverne informace, jejichz ochrana muze byt vyzadovana
pravnimi predpisy.
Jestlize jste zpravu obdrzel(a) omylem, neprodlene informujte jejiho
odesilatele a tuto zpravu, jeji prilohy a pripadne kopie ihned
vymazte. Jakakoli forma uziti, zverejneni, reprodukce, kopirovani,
distribuce a sireni teto zpravy je v takovem pripade zakazana.
Komercni banka, a.s., neodpovida za mozne skody zpusobene neuplnym
prenosem, moznou modifikaci ci zpozdenim teto zpravy behem prenosu od
odesilatele k adresatovi.
This e-mail transmission is intended solely for the ordinary user of
the e-mail address to which it was addressed. It may contain legally
privileged and/or confidential information.
If you have received this e-mail in error or are not an intended
recipient please inform the sender with-out delay and delete this
e-mail, attachments and possible copies immediately. The unauthorised
use, disclosure, distribution and/or copying of this e-mail or any
information it contains is prohibited.
Komercni banka, a. s., does not accept liability for any damage caused
by incomplete transmission, possible modification or delay of this
e-mail during the transmission from the sender to the recipient.
