Just Blog

Sunday, December 8, 2013

Mapping Persistent Objects

Mapping Persistent Objects

ამ სტატიაში ვისაუბრებთ თუ როგორ ხდება ენთით ბინების რელაციურ ბაზაში მოთავსება. შევეცდები, ყველაზე მნიშვნელოვან საკითხებზე ვისაუბრო. რასაც ვერ მოვასწრებ, შემდეგ სტატიაში შემოგთავაზებთ. დავიწყოთ.

@javax.persistence.Entity
@Entity ანოტაცია ფერსისთენს პროვაიერს ეუბნება, რომ შესაბამისი კლასი უნდა შეინახოს ბაზაში. ასე გამოიყურება ეს ანოტაცია:

როგორც ვხედავთ, აქ გვაქვს name() მეთოდო მხოლოდ. თუ სახელს არ გადავცემთ , დეფაულთად აიღებს ბინის სახელს.

@javax.persistence.Id
განსაზღვრავს, თუ კლასის რომელი ველი იყოს ბაზაში promary key.
პატარა მაგალითი:



შესაძლებელია XML შიც გავაკეთოთ იგივე (persistence.xml ში).
მაგალითად:

@javax.persistence.GeneratedValue

რაც შეეხება primary key ს, შეგვიძლია ჩვენ ჩვენთვითონვე განუსაზღვროთ, ან საშვალება მივცეთ რომ თვითონვე დაგენერირდეს.

ასე გამოიყურება ჩვენი შესაძლებლობები:

როგორც ვხედავთ, დეფაულთად AUTO გვიყენია. დანარჩენებზე 3 ზე, დეტალური გარჩევა შეგიძლიათ იხილოთ ამ ლინკზე. მარტივი მაგალითი:

@javax.persistence.Table

ენთითი მენეჯერს ვეუბნებით რომ შესაბამისი ანოტაციის მნიშვნელობა ეხება რელაციური ბაზის ცხრილს. კერძოდ მაგალითად ფხრილის სახელის განსასაზღვრავად.
მთლიანად კი ასე გამოიყურება:

@javax.persistence.Column
სვეტებზე სამუშაო ანოტაცია. სულ ეს მეთოდები გვაქვს:

რელიციური ბაზები ვინც იცის, ადვილად მიხვდება ყოველივეს. მაგალითად, name განსაზღვრავს სვეტის სახელს. table გამოიყენებას ახლა არ გავნმარტავ დეტაულად, თორე სხვა თემაზე მომიწევს გადახტომა- კერძოდ Multitable მეფინგის დროს გამოიყენება. მაგალითად, თუ გვინდა რაღაც ველები პარალელურად სხვა ცხრილშიც ჩავწეროთ. VARCHAR ის ზომას length განსაზღვრავს. დანარჩენიც ადვილი მისახვედრია ვინც რელაციური ბაზები იცით და აღარ გავაგრძელებ.

@Basic and FetchType

@Basic ანოტაცია არის დეფაულთი მონაცემების ჩამწერი შემდეგი ტიპის მონაცემებისთივს: java.lang.String, byte[], Byte[], char[], Character[], java.math.BigInteger, java.math.BigDecimal, java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time, java.sql.Timestamp .

არ არის საჭირო ჩვენ ვუთხრათ ფერსისთენს მენეჯერს თუ როგორ ჩაწეროს მონაცემები, ის ავტომატურად ჩაწერს ისე როგორც საჭიროდ ჩათვლის.

აგერ ვიხილოთ ჩაწერის სახეებიც.

თუ fetch() ატრიბუტი არის LAY, შესაბამისი ფროფერთის ინიციალიზება არ მოხდება მანამ, სანამ მასზე წვდომას არ მოვახდენთ. თუმცა აქ ერთი დეტალია გასათვალისწინებელი, ზოგადად @basic ანოტაცია არ არის პირდაპირ და ცალსახად განმსაზღვრელი თუ როგორ ვამუშაოთ პროგრამა. ეს უფრო მიმათითებელი არის, რომელიც შესაძლოა შესრულდეს სხვანაერადაც. ზოგმა JPA -ს იმპლემენტაციამ შეიძლება ეს აღიქვას, როგორც პირდაპირ განსაზღვრულად, ზოგმა შეიძლება არა. ანუ იმას ვამბობ რომ შეიძლება LAZY მივუთითოთ მაგრამ ინიციალიზება მაინც გაუკეთოს( ანუ EAGRLY სავით მოიქცეს). ეს მხოლოდ იმიტომ , რომ ოპტიმიზაციის გამო კარგად იმუშაოს - თვითნ ხვდება რომელი არის უკეთესი.

მოვიყვანოთ მაგალითი

XML შიც შეიძლება იგივე გავაკეთოთ:

@Temporal

საშუალებას გვაძლევს, რომ დამატებითი ინფორმაცია მივცემთ ფერსისთენს პროვაიდერს java.util.Date ან java.util.Calendar ზე. ანუ ამ ანოტაციის წყალობით შეგვიძლია შევინახოთ ბაზაში DATE, TIME, TIMESTAMP. მაგალითად გვინდა შევინახოთ ენთითს შექმნის თაღირი. ამაზე მაგალითსაც შემოგთავაზებთ ქვემოთ (სათითაოდ რომ არ ვწერო @Lob ზე და @Enumarated-ზე, ერთად დავწერ).

@Lob

ზოგჯერ არის შემთხვევები, როდესაც დიდი ინფორმაცია გვაქვს შესანახი ბაზაში. ამისათვის JDBC ში არის, მაგალითად, სპეციალური ტიპები ობიექტებისთვის. მაგალითად, ჩვენ ვიცით რომ java.sql.Blob არის binary მონაემებისთვის, ხოლო java.sql.Clob არის character მონაცემებისათვის. javax.persistence.Lob ანოტაცია არის სწირედ იმისთვის რომ შევინახოთ ესეთი ტიპის დიდი მონაცემები. (მაქალითს ქვემოთ დავწერ)

@Enumerated

ეს ანოტაცია საშვალებას გვაძლევს შევიანახოთ ენამის ტიპის მონაცემები ბაზაში.

ამ ბოლო სამ ანოტაციაზე მაგალითი კი ეს არის:

ახლა მოვრჩები წერას :) კიდევ აუცილებელი და მნიშვნელოვანი საკითხებია @Embeddable ობიექტები, Primary-Key კლასები, რელაციები ბაზებს შორის და ასე შემდეგ. როცა დრო მექნება გავაგრძელებ წერას:)

Monday, November 18, 2013

PRS MNG FlushModes

ამ სტატიაში ვისაუბრებთ FlushModeType-ზე.

ენამი გამოიყურება შემდეგნაირად:

public enum FlushModeType{
 AUTO,
 COMMIT
}

შესაბამისი მისამრთი:

################################
javax.persistence.FlushModeType
################################

იმის შემდეგ რაც persist(), merge(), remove() გამოვიყენებთ, ცვლილებები ბაზაში არ აისახება მანამ სანამ ენთითი მენეჯერი არ გააუკეთებს flush-ს. ჩვენ შეგვიძლია იძულებით მოვახდინოთ დასინქრონიზირება, თუ გამოვიყენებთ flush() მეთოდს. ზოგადად, დეფაულთად ისე არის კონფიგურირებული რომ, flush ხდება მაშინ, როდესაც ტრანზაქცია მთავრდება და ასევე მაშინაც, როდესაც რაიმე ქუერის ეგზექიუთს გავუკეთებთ - აქ დასაზუსტებელია query ში რას ვგულისხმობთ და რა გამონაკლისები არსებობს: მაგალითად, მოვახდინეთ რაიმე ობიექტის persist და შემდეგ find() ით დავაბრუნოთ შესაბამისი ობიექტი. შედეგი ის იქნება , რომ null დაგვიბრუნდება. find და getReference არიან ისეთი ტიპები, რომლებიც არ ახდენენ ბაზაში ცვლილებებს,
შესაბამისად, flush იც არ იქნება გამოძახებული, მის შესრულების შემდეგაც. აქ, getReference() ვახსენე, და ბარემ განვმარტავ რა განსხვავებაა ამათ შორის.

განსხვავება იმაში მდგოამრეობს რომ თუ find() -ს ვიყენებთ, თუ ბაზაში შესაბამისი ჩანაწერი არ მოიძებნა null დაბრუნდება, getReference()-ს შემთხვევაში კი javax.persistence.EntityNotFoundException-ს ისრვრის.

როდესაც შეეხეაბაზ FlushModeType-ს, დეფაულთად AUTO აყენია. ყველაფერს თავისი გამოყენება აქვს, გააჩნია რა ამოცანა გავაქვს გადასაჭრელი, შესაბამისად შეიძლება AUTO გამოგვადგეს, შესაძლოა COMMIT. ამიტომაც გვაქვს setFlushMode(), რომლის საშუალებითაც შეგვიძლია ვაკონტროლოთ flush -ის მუშაობა. მაგალთად, თუ ბევრი აბდეიტებია გასაკეთებელი, შეგვიძლია ფერფორმენსის მიზნით აბდეიტი ერთ batch ში გავაკეთოთ, ამისთვის სწორედ COMMIT გვჭირდება. მოვიყვანოთ მაგალითიც.

Saturday, November 9, 2013

EX $PATH Linux

წარმოვიდგინოთ სიტვაცია როდესაც პროგრამა დავაყენეთ და კლასფასში არ ჩაჯდა, მაგალითად:

linux:~ #  aming-ng

და გვეუბნება:

#If 'airmon-ng' is not a typo you can use 
command-not-found to lookup the package that contains it, 
like this:  cnf airmon-ng

პრობლემა ორიდან ერთია, არ პროგრამა არ მიყენია ან კლასფასში არ მიზის[ხდებახოლმე].

მოვძებნოთ სად გვიგდია ჩვენი airmon - [ან თუ არის საერთოდ]

linux:~ #  find / -name airmon-ng
/usr/local/sbin/airmon-ng

ისე მოსაძებნად ესეც შეგვიიძლია

linux:~ #  locate airmon-ng

კარგია, ახლა კლასფასი ვნახოთ:

 linux:~ #  echo $PATH
#/home/vakhoq/bin:/usr/local/bin
:/usr/bin:/sbin:/usr/sbin:/bin
:/usr/bin/X11:/usr/X11R6/bin
:/usr/games

როგორც ჩანს ჩვენი პროგრამ არ ზის. ოკ ჩავსვათ მარტივად:

linux:~ #  export PATH=$PATH:/usr/local/sbin

სულ ეს იყო, შევამოწმოთ ფასი:

linux:~ # airmon-ng

და მივიღეთ აუთფუთი:

Interface       Chipset         Driver

wlan0                   ath9k - [phy0]

Tuesday, November 5, 2013

EJB PersistenceContextTypes

EJB 3.X ში გვაქვს extended persistence context და მეორეა transaction-scoped. თუ მეორეზე გვაქ საუბარი, ბინის ინსტანსი არის წვდომადი [managed] მანამ სანამ ტრანზაქციაში ვართ [ტრანზაქცია როგორც კი მორჩება, წვდომა აღარ გვექნება, ამ მდგოამრეობას detached-ს ვუწოდებთ]. ანუ როგორ კი ტრანზაქცია დამთავრდება პერსისთენს ობიექტები გახდეაბიან detached.

თუმცა სხვაგვარად გვაქვს საქმე extended scoped კონტექსტში. მიუხედავად ტრანზაქციის დასრუელბისა, ენთითის ინსტანსი რჩება წვდომადი კვლავ - ყველა ობიექტის ისნტანცი რჩება წვდომადი.

ანუ ეს ორი ვარიანტი გვაქვს:

PersistenceContextType.EXTENDED
PersistenceContextType.TRANSACTION

მაგალითად, შევქმნათ Stateful (!)) ბინი.

@Stateful
public class ShoppingCartBean implements ShoppingCart{

   @PersistenceContext(type=PersistenceContextType.EXTENDED)
   EntityManager em; 

   private Account account

   public void addAccount(){
      account= new Account();
      account.setName("valhtang");
      account.setAge("21");
      em.persist(account)
   }


   public void updateAge(){
      account.setAge("22");
   }

}

თუ, EXTENDED არ გვექნებოდა, როდესაც addAccount შესრულდებოდა, ტრანზაქციაც მორჩებოდა, და updateAge სთვის შეცვლიდა მხოლოდ detached entity ინსტანსს, და რათმქაუნდა ეს ბაზაზე არ მოახდენდა გავლენას. ამ შემთხვევაში კი, ტრანზაქციის დასრულების შემდეგაც გვაქვს წვდომა.

kernel/debug/vgaswitcheroo

ლეპტოპობი, რომლებსაც ჰიბრიდული ვიდეო კარტა აქვთ [იგულისხმება, როდესაც 2 ვიდეო კარტა არის ლეპტოპზე, ძმლავრი მხოლოდ მაშინ ირთვება, როდესაც ამის რესურსი არის საჭირო. მიზანი ამ ვიდეო კარტების შექმნისა იყი ის რომ, დაეზოგად ბატარეის რესურსი. ცხადია GT 550 M რომ იყოს სულ ჩართული, ერთ საათიც არ დაჭირდება ბატარეა მთიანად რომ დასვას], საჭიროებენ ოპტიმიზაციას.

ერთერთი საშვალება ეკონომიის გასაკეთებლად არის პროექტი სახელად Bumblebee რომელიც რათქმაუნდა იდეალური არ არის, თუმცა ნელნელა ახალ ფუნქციონალურობას უმატებენ, და თანდათან უკეთესი ხდება. მეორე საშვალება კი ეს არის მექანიზმი კერნელისა, რომელსაც vga_switcheroo ვუწოდებთ. დავიწყოთ განხილვა:

vgaswitcheroo საშვალებით ადვილად შეგვიძლია ვაკნტროლოთ ჩვენი ვიდეოკარტების მუშაობა). vgaswitcheroo არის მექანიზმი კერნელში [ისე ზოგს სისტემა linux გონია, არადა მხოლოდ კერნელია ეს სისტემა კი Gnu/Linux] რომლის საშვალებითაც შეგვილია გადავერთოდ სხვადასხვა ვიდეოკარტებზე [ან ერთი გავთიშოთ ან მეორე და ასე შემდეგ]

იმის გასაგებად თუ რა ვიდეოკარტები გაქვთ შეგიძლიათ მარტივად მოვძებნოთ:

lspci | grep 'VGA'

და შედეგიც გვაქვს:

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 540M] (rev ff)

შეგვიძლია ასეც შეცამოწმოთ ჩვენი ვიდეოკარტები:

lspci -vnn | grep '\''[030[02]\]'

-ეს მექანიზმი ყველა გნუ/ლინუქსში არის ჩადებული?
- გააჩნია ვიდეო კარტის რა დრაივერს იყენებს. მხოლოდ იმ შემთხვევაში არის თუ უფენსორს დრაივერს იყენებს სისტემა. კერძოდ nouveau, radeonს. თუ Nvidiaსას იყენებს ან fglrx-ს, მაშინ არ აქვს. და შეგვიძლა შევამოწმოთ კერნელში არის თუ არა ჩადებული შემდეგნაირად:

grep -i switcheroo /boot/config-*
CONFIG_VGA_SWITCHEROO=y

შეგვიძლია შევქმნათ სკრიპტი, რომელსაც ხელით გავუშვებთ ხოლმე.

vakhoq@linux:~> cd [dir]>
vakhoq@linux: [dir]>  touch hybrid.sh
vakhoq@linux: [dir]>  vi hybrid.sh

შიგნით ვწერთ მაგალითად ვიდეოკარტის გათიშვას.

###################################################
#!/bin/sh

# მხოლოდ გავთიშოთ მეტი არაფერი
echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
####################################################

ვინახავთ :wq საშვალებით. მოკლედ, Nvidia ვთიშავთ, რათა ინტეგრირებულზე იყოს მხოლოდ ჩვენი ლეპტოპი. (გაითვალისწინეთ ფერმიშენები იქნება საჭირო ამ სკრიპტის გასაშვებად. ამიტომ sudo ან su გამოიყენეთ)
პ.ს საერთოდოდ rc.local ში შეგიძლიათ ჩააგდოთ სკრიპტი. ან after.local ში , გააჩნია რომელ დისტროს იყენებთ. rc.local უბუნტუში after.local კი OpenSuse ში).

ამასთან სტატუსების შემოწმება, თუ რა მდგომარეობაშია ჩვენი ვიდეო კარტა შეგვიძლია შემდეგნაირად:

cat /sys/kernel/debug/vgaswitcheroo/switch

შევამოწმოთ რამდენად ოპტიმალურია ჩვენი სამუშაო.

ამისთვის ჯერ ჩავთოთ/გამოვრთოთ ვიდეოკარტაზე წვდომა, შემდეგ სტატუსები გამოვაჩინოთ და acpi საშვალებით დროებიც ვნახოთ (დებიანზე apt-get install acpi , suse zypper install acpi და ასე შემდეგ)

#############################################################
vakhoq@Gnulinux:~> su
Password: ******


Gnulinux:/home/vakhoq# echo ON > /sys/kernel/debug/vgaswitcheroo/switch
Gnulinux:/home/vakhoq # cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :Pwr:0000:01:00.0
linux:/home/vakhoq# acpi
Battery 0: Discharging, 85%, 00:55:07 remaining


Gnulinux:/home/vakhoq# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
Gnulinux:/home/vakhoq # cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :Off:0000:01:00.0
Gnulinux:/home/vakhoq# acpi
Battery 0: Discharging, 85%, 01:35:12 remaining
#############################################################

როგორც ხედავთ საკმაოდ კარგი შედეგები გვაქვს.
ახლა სათითაოდ განვამრტოთ რას ნიშნავს გამონატილი შედეგები
IGD - ნიშნავს Integrated Graphic Device (ძირითადად Intel)
DIS: denotes DIScrete graphic device (nVidia ან ATI)
+ რომელსაც უწერია, ნიშნავს რომ ის ვიდეოკარტაა აქტიური.
დანარჩენს აღარ გავნამრტავ, ისედაც ცხადია. :)

Monday, October 28, 2013

Jboss AS7, Datasource configuration

მოკლედ, დღეს ვისაუბრებთ Datasource configuration-ზე. კერძოდ mysql სერვერს დავუკონფიგურირებთ EJBს, რომელიც Jboss 7.1 ზე იქნება გაშვებული.

1) შევდივართ სერვერის modules ფოლდერში და com\mysql\main ფოლდერში module.xml ში ვწერთ:

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
     <resources>
              <resource-root path="[connector-jar]"/>
     </resources>
     <dependencies>
             <module name="javax.api"/>
     </dependencies>
</module>

ამასთან აქვე ვაგდებთ mysql-connector-java-[version]-bin.jar -ს. დაგუგლეთ და გადმოწერეთ, დეტალური ინფორმაციისათვის ასევე just google

ყურადღება მიაქციეთ name="com.mysql" - იგივე გამეორდება დრაივერებში.

2) standalone\configuration-ში, ხსნით თქვენს შესაბამის standalone-[version].xml-ს(რომლითაც უშვებთ სერვერს - არ გავნმარტავ ამ თემას). აქ ვამატებთ დატასორსებში დრაივერს:

 <driver name="mysqlDriver" module="com.mysql">
  <xa-datasource-class>com.mysql.jdbc.Driver</xa-datasource-class>
 </driver>

თვითონ დატასორსს აქ არ ვაგდებთ, განცალკევებით -ds.xml ფაილს გავაკეთებთ და დეპლოი ფოლდერში ჩავაგდებთ. თუმცა ასეც აკეთებ. მაგრამ დიზაინის მხრივ არ მიმაჩნია სწორე მიდგომად სტენდელოუნში კონფიგურაცია.

3) deployments ში ვაგდებთ [name]-ds.xml-ს:

<datasources>
      <datasource jndi-name="java:/MySQLDS" pool-name="MySQLDS" enabled="true" use-java-context="true">

                    <connection-url>
                         jdbc:mysql://localhost:3306/db
                     </connection-url>

                    <driver>mysqlDriver</driver>

                    <security>

                           <user-name>[usr]</user-name>
                           <password>[pass]</password>
                    </security>

       </datasource>
</datasources>

4) დავაკონფიგურიროთ ბაზასთან ჩვენი აპლიკაცია. მოკლედ შევდივართ ჩვენი აპლიკაციის ejbModule -ის META-INF ფოლდერში და ვქმნით persistence.xml-ს

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
  <persistence-unit name="JPADB">
  <jta-data-source>java:/MySQLDS</jta-data-source>
    <properties>
     <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
     <property name="showSql" value="true"/>
     <property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>
    </properties>
  </persistence-unit>
</persistence>

აღარ გავბმარტავ აქ persistence-unit რა არის, და property ების მნიშვნელობები რას ნინშავს jta-data-source სი. არსებობს გუგლი და დოკუმენტაცია ამისთვის :)

Saturday, October 26, 2013

lz init, dc locking, volatile

ამ სტატიაში ვისაუბრებთ შემდეგ თემებზე:
->lazy initialization
->Singleton
->double-checked locking
->volatile (JIT ში და ASM შიც)

Ok, lets start it!...

### lazy initialization ####

lazy initialization არის ტაქტიკა, როდესაც თქვენ აფერხებთ ობიექტის შექმნას. ამასთან ომპიტიზაციასაც ვაკეთებთ.

class ResourceManager{ 
private Resource resource;
  public Resource getResource(){

    if ( resource == null ){
      resource = new Resource();
    }
    return resource;
  }
}

შევხედოთ სრდედების თვალით, რა შეიძლება მოხდეს. მოვიდა სრედი I , ნახა ობიექტი არის ნალი, და შექმნა ობიექტი. ამასთან, II სრედმაც ნახა რომ null არის და შექმნა... თუ გვინდა, რომ ორივე სრედს ერთიდაიგივე instance ქონდეს, მაშინ singleton დაგვჭირდება (ერთერთი GoF Design Pattern იდან).

### singleton Pattern ####

class Resource{
  private static Resource instance;
  public static Resource getInstance(){
    if ( instance == null){
      instance = new Resource();
    }
    return instance;
  }
}

როდესაც აქ მულტი სრედინგით დავიწყებთ ყურებას synchronized დაგჭირდება... მაგრამ, როდესა ერთ სრედი გაეშვება პრობლემა lock-ისა დაგვხვდება.... ამ პრობლემის გადასაჭრელად Double-Checked Locking პატერნი გამოვიყენოთ...

### Double-Checked Locking ###
ამ შემთხვევაში, მეთოდები არ არიან დასინქრონიზირებულები (წინა შემთხვევაში გვქონდა და ლოქის პრობლემა გვქონდა),
არამედ ინსტანსის შექმნის კოდი ჩაჯდება სინქრონიზაციის ბლოკში.

class Resource{

  private static Resource instance;
  public static Resource getInstance(){
    if ( instance == null ){
      synchronized(Resource.class){
        if ( instance == null ){
          instance = new Resource();
        }
      }
    }
    return instance;
  }
}

თუ ერთი სრედი შესული არის სინქრონიზაიის ბლოკში, სხვები დაელოდებიან სანამ ინიციალიზება არ მოხდება.

პრობლემა ისაა რომ ინიიალიზება და ობიექტის შექმნა სხვადასხვა ადგილასაა. ანუ , პრობლემა ისაა, რომ ერთი სრედი სანამ სინქრონიზაციის ბლოკშია, მეორე როდესაც შემოვა ( და ამასთან იმის გამო რომ instancce==null), ეს სრედი ეცდება შექმნას ობიექტი... ოოპს! გავიჭედეთ! stuck in the desert! - ფიქრის შედეგად აღმოვაჩენთ , რომ ის არ არის რაც ჩვენ გვიდნა. ნუ, თუ არ ვიფიქრეთ ვერც აღმოვაჩენთ.

(პ.ს ისე ამაზე ინფო დეტალურად Java Concurrency in Practice წიგნში შეგიძლიათ წაიკითხოთ, ეს არის ძალიან ძალიან მაგარი წიგნი, და ყველა პროგტამისტს უნდა ქონდეს წაკითხული. ამაზონზე თან სულ ახლახანს გაიაფდა).

აბა პრობლემას როგორ გადაჭრით? რამდენიმე გზა არსებობს. აი იმ წიგნში მე რომელიც გითხარით, იქ ნახავთ დაწვრილებით ისე ყველაფერს. უცბათ ერთერთ გზას შემოგთავაზებთ:

class Resource{

  private static class ResourceHolder{
    static final Resource instance = new Resource();
  }

  public static Resource getInstance(){
    return ResourceHolder.instance;
  }

}

მოდით გავაგრძელოთ და ეგრედ წოდებული volatile ზე გადავიდეთ და თან ამ თემასაც დავუკავშირებთ.

მოკლედ, იმისათვის რომ volatile ზე ვისაუბროთ, ჯერ ჯავას memory model უნდა ვიცოდეთ, თუ როგორ მუშაობს - ყველა სრედი, ჯავაში, გამოიყოფს თავის ცალკეულ ადგილს მემორიდან. ანუ თუ კვენ ერთ სტორიჯს გამოვუყობთ ყველაფერს ეშველება - გავიხარებთ ყველანი. ანუ ვიპოვეთ გზა რითიც Virtual Mahine-ს ვაიძულებთ რომ არ შექმნას ტემპორარი კოპოიოები ცვლადების. (მოკლედ, ბევრს აღარ გავაგრძელებ, სიღრმისეულია ეს თემა, და atomc variable ზე ბევრი რამეს დაწერა შეილება - სალაპარაკოს რა გამოლევს, დრო ვთქათ თორე...)

პატარა მგალით მოვიყვანოთ. წარმოიდგინეთ ორი სრედი, ერთში ცვლადს ენიჭება მნიშვნელობა, მეორეშ სრედში ამ ცვლადს ვკითხულობთ პირდაპირ. ეს შეილება მარტივად გამოვიყენოთ სრედის გაჩერებაშიც (რათქმაუნდა interruptი შეგიძლიათ), მხოლოდ loop დაგვჭირდება.

public void run(){
 while(stop!=true){
  // სრედი არ კვდება
 }
}

ვიზუალურადაც ვაჩვენოთ. ორი სრედი. როდესაც ერთში შეიცვლება მნიშვნელობა, მეორე იგივე STORE დან იღებს. მოკლედ ASM ში როგორ არის იმას დაბლა დავწერ. ჯერ ეს საკმარისია.

ასეთი რამეც შეიძლება გავაკეთოთ (აქაც იგივე გავაკეთე, პროსტა, ობიექტის რასაც ვანიჭებთ volatile არის. სხვა არაფერი). ანუ დარწმუნებული ვართ რომ თუ ერთმა სრედმა მნიშვნელობა მიანიჭა ცვლადს, მეორე ცვლადში ეგრევე აისახება.

class Foo {

  private volatile Helper helper = null;
  public Helper getHelper() {
    if (helper == null) {
      synchronized(this) {
        if (helper == null) {
          helper = new Helper();
        }
      }
    }
  return helper;
}

ახლა JIT ში რახდება ის ვნახოთ. რაც არ უნდა იყს, ვერ გავექცევით, JIT ში ომპტიმიზაცია ასე მოხდება

while (test.loop == true) ;

// გადავა შემდეგ კოდში =>

if (test.loop) { while (true); }

ოკ, და რეალურად მთლიანი STORE შეინახება EAX რეგისტრში.

volatile მდე იქნებოდა:

00000068  test        eax,eax 
0000006a  jne         00000068 

//შემდეგ კი 

00000064  cmp         byte ptr [eax+4],0 
00000068  jne         00000064

ყოველი სრედი, იგივე მემორიდან ამოიღებს ცვლადის მნიშვნელბოას (ptr [eax+4])

რა კითხვებიც გექნებად დაწერეთ, არ მოგერიდოთ! :-)