Keresés

Köszi!

Igazából a JDBC-vel képben vagyok és az SQL-lel is, ott vesztem el a fonalat amikor képbe jön a perzisztencia.
És nem is magával a perzisztencia mibenlétével (de szép.. :-) ) van gondom, csak nem tudom merre induljak el. Nehéz ezt így írásban visszaadni.
Az a gondom hogy nem akarok egyelőre mással foglalkozni csak készíteni egy desktop alkalmazást ami egy adatbázissal kommunikál: egy primitív CRUD alkalmazás.
Viszont ha a neten elkezdek keresgélni JPA meg Hibernate téren, egyből jönnek a webalkalmazások, ANT, SPRING, Rail meg még a franc tudja mi. Nagy részéről azt sem tudom mi, és egyelőre nem is érdekel mert a Java SE-t szeretném profi módon elsajátítani, meg a JPA-bó annyit ami desktop alkalmazáshoz kell.
Magyarul egységsugarú java kódolóként fogalmam nincs mi hasznos és mi nem :-)

Most nezem, hogy a http://www.javapassion.com/-on az IMF-es GDP/fo (PPP) listan nem top 40-es orszagok lakosai egy 30% kedvezmenyt kapnak. Igy szerintem meg inkabb megeri.
/ Ez egyebkent tartalmazza azt is, hogy kurzusszeruen csinalhatod a kulonbozo targyakat/temakat, hazi feladattal mindennel egyutt.

Jon vki Devoxx-ra? (Antwerpenben)

Lesz Brian Goetz, Josh Bloch meg java puzzlers, minden mi szem-szajnak ingere. :-)

Tanulassal kapcsolatban: van hivatalos JPA site, ahogy az altalad felsorolt perzisztencia manager framworkoknek is. Ha nem akarsz mindegyikkel foglalkozni, akkor en a Hibernate-t emelnem ki, mert azt sok helyen onmagaban is hasznaljak.
Ezen kivul en anno a javapassion.com oldalon talaltam sok nagyon jo tananyagot. Sajnos ma mar ez nem ingyenes hala az Oracle-nek aki kitette az addig a SUN-nal dolgozo architectet aki az oldalt kezeli. Ettol fuggetlenul ha ugy gondolod, hogy meger ez neked 1-2 java konyv (<100USD), akkor erdemes elofizetni az oldalra, mert nagyon sok hasznos tananyag van, raadasul peldafeladatokkal es megoldasokkal.

En javaslom meg elotte a JDBC tanulmanyozasat es *megerteset*. Nem vagyok ellene, sot nagyon is hasznosnak talalom az ilyen frameworkoket, de ha a fejleszto nincs tisztaban legalabb nagy vonalakban avval, hogy ilyenkor mi tortenik a hatterben az sokszor rossz dontesekhez vezethet.
Az en adatbaziskezeles utvonalam az alabbi lenne (feltetelezve az SQL es nemi J2SE tudast):
JDBC -> Perzisztencia Man. -> JPA
Ez az en szubjektiv velemenyem, el lehet tole terni. Ahogy korabban emlitettem per. man.-bol a Hibernate-t ajanlom. De itt is el lehet idozni olyanokkal, mint pl. second-level cache hasznalata, sot esetleg implementacioja. Ezeket csak arra az esetre mondom, ha mar ugy erzed, h nagyon kepben vagy a dolgokkal, erdemes utana nezni, mindig van mit tanulni meg.

Sziasztok!

Tanácsot kérnék hogy hogyan fogjak hozzá a JPA-val való ismerkedéshez?
Előre is bocs az iszonyat pongyola megfogalmazásért.
Arról lenne szó hogy a java SE-vel már viszonylag ki vagyok békülve (Angster meg Nyékiné-féle könyvek), de az adatbázis-kezeléses feladatok miatt már nem tudom kikerülni a továbblépést.
A gondom az, hogy bármennyit is "guglizom", teljes a káosz bennem a Hibernate, EclipseLink, TopLink és társaival kapcsolatban.
A dolog ott kezdődik hogy Netbeans-t használok. Létrehozok egy üres java alkalmazás projektet, abban létrehozok egy JFrame-osztályt, arra pakolok pl. egy JTable-t, arra ráhúzok egy adatbázis-táblát (pl. szallitok) a "Services"-ablakból.
A Netbeans legenerál egy szallitok.java állományt ami az entitásokat tartalmazza, még ez is ok mert kb. tudom miről van szó.
Létrejön egy persistence.xml amivel megadom a persistence provider-t(?) EclipseLink vagy Hibernate vagy Toplink.
És itt veszítem el a fonalat, mert a primitív teszt-alkalmazás működik, viszont nem tudom hogy mi történik a háttérben.
Ha a neten keresek példákat, mindenhol olyant találok ahol egy rakás xml file-t kell kézzel létrehozni meg szerkeszteni. Ez is OK lenne, de én az előbbi projektben nem találok ilyeneket.

Gondolom látjátok hogy elég nagy a zavar bennem :-)
Annyira tudok java-ban programozni hogy IDE nélkül is összehozok egy alap swing-es guit, mert tudom mi történik, tudom mi miért van. Itt viszont totál tanácstalan vagyok.
A másik, hogy nem is tudom mivel érdemes kezdenem, mert nem akarok elavult/túlhaladott technológiával foglalkozni.

Segíthetnétek hogy hol induljak el, mit érdemes beszereznem, honnan tanuljak.

okok, implicit benne volt a k-ban a counter. :) beleerzessel, megertheto volt ugy is.

... k++, k---, whatever;

... counter++, counter---, whatever;

faradt vagyok mar.

Koszi!

Folfogtam a dolgot.

... get/setCounter(...)

... myThread.get/setCounter(...)

Gyakori felreertes a class es a thread osszekeverese ilyenkor.
A te eseted sokkal egyszerubben (es olvashatobban):

Class MyThread extends Thread{

private int counter = 0;
private final Object mutex = new Object();

void run(){
for(...){
synchronized(mutex){
... k++, k---, whatever;
}
}
}

public int getCounter(){
synchronized(mutex){
return counter;
}
}

public void setCounter(int c){
synchronized(mutex){
this.counter = c;
}
}

}


Class OtherThread extends Thread{

private MyThread myThread;

OtherThread(String name, MyThread myThread){
super(name);
this.myThread = myThread;
}

void run(){
for(..){
... get/setCounter(...)
}
}
}

Javában hamar hozzá fogsz szokni ahhoz, hogy mindenhez wrappert csinálj. Sokakat bosszant, de szerintem ha nem ész nélkül csinálja az ember, a végeredmény sokkal olvashatóbb.

hihi!

Fejlodom, ugy tunik. Meg ezen hozzaszolasod elott potyogtem be a magamet. :))))

igen ez volt a cel.
A benazasom onnan indult, hogy nem akartam sajat osztalyt kesziteni egy nyomoronc counter kedveert, es olyan siman elsiklottam az Integer immutable volta felett, hogy meg magam is kinevettem magam. Nem megy sajat "Integer" class nelkul a dolog.

(Koszonet el Papinak, hogy ismetelten folhivta erre a figyelmemet. )


Aztan mostmar megemesztettem azt is, hogy ezen a modon ahogy en csinatam nem eleg, ha az egyik szal hasznal egy lockot. Itt talan megis objektum orientalt vagyok :D , ha nagyon szeretnem egy objektumhoz kotni a lockolas problematikajat, es mas objektumnal ami hozzaferne a kritikus szalbiztos valtozohoz, mar nem szeretnek mindenfele lockokkal bajlodni, a tobbi szal ne is tudjon a dologrol, legyen az a szalbiztos valtozot tartalmazo obj dolga.

Ez viszont valoban csak szinkronizalt setter/getter metodusokkal megy, nem szinkronizalhatok a valtozora.

Tobb problema van:
statikus hivatkozas instance-on keresztul.
az objektum orientalt nyelvbol eredoen nem modositunk/olvasunk direkt valtozokat, plane nem multthreading kornyezetben.
Egy mutexet nagyon nem szerencses kulonbozo classokban hasznalni. En csinaltam anno ilyet elsosorban performance okok miatt, de ezzel gyakorlatilag oda is lett a kodom karbantarthatosaga. Nagyon kenyes dolog az ilyesmit debugolni, es akkor gondolj bele abba, ha nem is a sajat kododrol van szo.
Szoval mindig igyekezz hazon (classon) belul tartani a thread safety-t biztosito kodot.

:) oooo! szemafor ugyben meg ugyetlenebb vagyok.

Nincs problema. Egy szerencsetlen szamlalot probalok ket szallal toszogatni ugy, hogy bizonyos helyeken a kodban biztonsagban erezzem magam, ezeken a helyeken ne kaphasson lehetoseget mas szal.

Ez kivitelezheto, de nagyon nem ajanlott ilyet csinalni.

Miert nem ajanlott ez? Mi a gond ezzel?

Amennyiben az a celod, hogy a SimpleCount1 peldanyod ciklusmagjanak mukodese olyan legyen hogy minden iteracional kiirt szampar kozti kulonbseg 1 legyen, akkor igen.

Szerintem is az lenne a legszerencsesebb ha a eloszor is tisztaznank mi az alapveto megoldando problema.

igy mar akkor ok?!

class SimpleCount2 extends Thread {
Thread masikSzal;
SimpleCount2(String name, Thread masikSzal) {
super(name);
this.masikSzal = masikSzal;
}
public void run() {
for (int i = 1; i <= 500; ++i)
synchronized ( ((SimpleCount1) masikSzal).myInteger ){
((SimpleCount1) masikSzal).myInteger.incIntValue(2);
}
}
}

((SimpleCount1) masikSzal).myInteger.incIntValue(2);

Itt egy instance-bol probalsz hivatkozni egy statikus mezore. Teljesen felesleges a 'masikSzal'. Az alabbi teljesen ugyanezt csinalja es olvashatobb:

SimpleCount1.myInteger.incIntValue(2);

Amugy az objektum orientacio alapelveivel utkozik egy ilyen direkt valtozo eleres.

Tehát akkor lényegében egy szemaforra lenne szükséged?

Nekem erősen az az érzésem, hogy túl messzire elmentél egy irányban a megoldás fele, mielőtt még tisztáztad volna, mi a megoldandó probléma.

Ehhez az kene, hogy a SimpleCount2-ben szereplo MyInteger modosito muvelet is ugyanazon lock-ot szerezze meg.
azaz synchronized(SimpleCount1.myInteger) {...}

Ez kivitelezheto, de nagyon nem ajanlott ilyet csinalni.

Ez egyaltalan nem thread safe. A SimpleCount2 peldanyod minden akadaly nelkul fogja a MyInteger-edet modositani, es SimpleCount1 peldanya is, mivel csak o hasznalja a lockot.

synchronized (myInteger) {
System.out.print( getName()+ ":" + myInteger.getIntValue()+" ");
myInteger.incIntValue(1);
System.out.println( getName()+ ":" + myInteger.getIntValue());
}

az lenne a feladat, hogy a ket kiiras altal szolgaltatott ertek kozott mindig 1 legyen a kulonbseg

Ez biztositana?

package threadproba1;

class MyInteger {
private int i;
MyInteger(int i) { this.i = i; }
public void incIntValue(int n) { i+=n; }
public int getIntValue() { return (i); }
}

class SimpleCount2 extends Thread {
Thread masikSzal;
SimpleCount2(String name, Thread masikSzal) {
super(name);
this.masikSzal = masikSzal;
}
public void run() {
for (int i = 1; i <= 50; ++i)
((SimpleCount1) masikSzal).myInteger.incIntValue(2);
}
}

public class SimpleCount1 extends Thread {
volatile static MyInteger myInteger = new MyInteger(0);
SimpleCount1(String name) {
super(name);
}

public void run() {
for (int i = 1; i <= 50; ++i) {
synchronized (myInteger) {
System.out.print( getName()+ ":" + myInteger.getIntValue()+" ");
myInteger.incIntValue(1);
System.out.println( getName()+ ":" + myInteger.getIntValue());
}
}
}
public static void main(String[] args) {
Thread thread1 = new SimpleCount1("th1"), thread2 = new SimpleCount2("th2", thread1);
thread1.start();
thread2.start();
}
}

Ha multithread kornyezetben egy valtozot tobb thread hasznal egyszerre, akkor biztositani kell explicit vagy implicit a szalbiztonsagot.
"Magatol" nem lesz szalbiztos. A te esetedre ott van az AtomicInteger amivel implicit biztositod a szalbiztonsagot. Ha olyan adattipust hasznalsz ahol ez nincs biztositva, ott ez neked kell explicit elvegezni.

ez vilagos:

private int k;

public void setK(int k){
synchronized(mutex){
this.k=k;
}
}


ugy kerulod meg a problemat, hogy nem engeded, hogy egy masik szal kozvetlenul hozzaferjen a k valtozohoz, csak a publikalt es szinkronizalt setK() metodussal.

tehat nem k-ra szinronizalsz (primitivre ugyebar nem is lehet), hanem eldugod k-t, hogy hozza se ferjen semmifele szal, es a beallito metodust szinkronizalod, egy csak erre a szinkronizalcio celjara gyartott mutex-szel.

Tehat megkerulod a problemat. :)

Akkor az nem muxik, hogy egy pl osztalyszintu publikus, statikus countert szalbiztosan kezeljunk kozvetlenut setter()/getter() metodusok kihagyasaval?

A masodik peldaban benne maradt a getter deklaracioban a synchronized, az ertelemszeruen nem kell oda.

el Papi!
Megprobalom osszfoglalni a korabbiakat:
Idaig azon gorcsoltunk, hogy Integer nem, Object mutex igen, meg hogy ertheto okbol ez azert legyen static...

Object mutex nem ok, ez kiderul, ha jol latom. Igy van?

Javitsatok ki, ha nem jol gondolom, most tehat ott tartunk, hogy a mutexes megoldas zsakutca, vegyuk elo a synchronizalt getter-setter megoldast, es csak ne nyulkajak k-hoz mas szalakbol publikusan.


Class MyClass{
private int k;

public synchronized void setK(int k){
this.k=k;
}

public synchronized int getK(){
return this.k;
}
}

es ugyanez kulso monitorlockal:

Class MyClassWithMutex{
private int k;

private final Object mutex = new Object();

public void setK(int k){
synchronized(mutex){
this.k=k;
}
}

public synchronized int getK(){
synchronized(mutex){
return this.k;
}
}
}

A kulonbseg az hogy az elso verzioban synchronized(this) a masodikban pedig synchronized(mutex) van.