Программирование

Hibernate: Ошибка при сохранении объекта NonUniqueObjectException

NonUniqueObjectException: a different object with the same identifier value was already associated with the session

Данная ошибка проявляется в момент вызова saveOrUpdate() у hibernate template. Суть проблемы в том, что в один момент времени у нас есть два разных объекта с одинаковым идентификатором: один в сессии, а второй тот, что мы пытаемся сохранить.

Person p1 = (Person)getHibernateTemplate().get(Person.class, 1);

...

// здесь мы хотим сохранить Person с именем Alex

// и id = 1 (при том, что у нас уже есть объект p1 в сессии)

Person p2 = new Person();

p2.setId(1);

p2.setName("Alex");

hibernateTemplate.saveOrUpdate(p2); // NonUniqueObjectException

Управление памятью в Objective C

При разработке софта под iPhone, столкнулся с проблемой непонимания механизма распределения памяти. Являясь java-разработчиком, привыкшим к чудесам Garbage Collector'а, тема памяти в Objective C поначалу доставляла мне массу неприятностей. Спустя некоторое время, написав свое первое приложение, я подумал, что полностью разобрался в этой непростой теме... и это было моей ошибкой. Все таки, сначала надо хорошо читать мануалы и желательно до конца :)

Назвал я данную тему непростой не из-за сложности механизмов управления памятью - они то как раз более-менее понятные и простые, а, скорее, из-за того, что не разобравшись до конца, как правильно "освободить" объект из памяти, можно получить массу сложноотлавливаемых ошибок типа EXC_BAD_ACCESS, причем необязательно именно в том месте, где была допущена ошибка распределения памяти.

Cocoa / iPhone: отладка ошибки EXC_BAD_ACCESS

Если вы хоть раз занимались разработкой программного обеспечения под iPhone, то наверняка встречались с ошибкой EXC_BAD_ACCESS. Отловить ее достаточно непросто, т.к. встроенный дебагер не покажет вам нужный стектрейс и тем более не подскажет, как все исправить.

Что же такое EXC_BAD_ACCESS? Мне удобнее сравнивать эту ошибку с NullPointerException в Java, т.к. возникает она в ситуации, когда вы отправляете "сообщение" объекту, который уже был выгружен из памяти (released). Например, попробуйте создать объект с помощью alloc и затем два раза подряд его "отпустить" с помощью release.

Так как же быть, если у нас достаточно большой проект с массой кода и объектов? Как проще и быстрее отловить данную ошибку? На помощь придет директива NSZombiEnabled, установленная в переменных окружения проекта. Все, что она сделает - это заставит Objective C runtime оставлять объект-пустышку за каждым выгруженным реальным объектом и в следующий раз, когда вы попытаетесь обратиться к своему выгруженному объекту, вызов пойдет именно к пустышке, которая остановит выполнение кода и выведет короткое и ясное сообщение в дебагер о том, какой объект был вызван и что за сообщение ему было отправлено. Стектрейс при этом также не будет испорчен, и сможет дать дополнительную информацию о месте баги.

2010-01-08 16:21:35.802 My Project[4833:207] *** -[NSMutableURLRequest release]: message sent to deallocated instance 0x4925f30

Cocoa / iPhone: форматирование даты

Простой пример для тех, кто ищет простой и быстрый путь отформатировать дату при разработке под iPhone. В моем примере будем форматировать дату по стандарту RFC2822.

NSString *rfcDate = @"Mon, 4 Jan 2010 20:41:12 +0300";

NSDateFormatter *formatter = [[NSDateFormatter alloc] init];

/* Установка локали обязательна, т.к. иначе будет использована текущая */

NSLocale *enUS = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US"];

[formatter setLocale:enUS];

[enUS release];

[formatter setDateFormat:@"EEE, dd MMM yyyy HH:mm:ss ZZ"]; 

NSDate *theDate = [formatter dateWithString:rfcDate];

Данный подход достаточно прост и эффективен, но у него есть один минус - куча строк, которые придется писать каждый раз, когда надо сделать преобразование. Чтобы этого избежать можно сделать так:

Взаимодействие между потоками в Java. Wait и notify.

Представим ситуацию, что у нас многопотоковое приложение, написанное на Java. Есть некий класс, выполняющий какое-либо конкретное действие с данными, например, отправку их по почте, а сами данные подготавливаются в другом месте кода в другом потоке. Перед отправкой данных нам необходимо как-то связаться с потоком, подготавливающим данные, дабы поймать момент, когда они будут готовы.

Пример 1. Простой, но неправильный пример

public class DataManager {

    private static boolean ready = false;

    public void sendData() {

        while (!ready) {

            // waiting

            System.out.println("Waiting for data...");

        }

        // continue execution and sending data

        System.out.println("Sending data...");

    }

    public void prepareData() {

        System.out.println("Data prepared");

        ready = true;

    }

}

Регулярно выражаемся в Java

Регулярные выражения в Java? А почему бы и нет, как говорится. Время от времени неизбежно появляется необходимость их использовать, чтобы разбить строку на подстроки или, например, отформатировать данные. Сделать это можно несколькими разными способами.

Способ первый, он же самый простой, для несложных манипуляций - использовать встроенные методы класса String для работы с регулярными выражениями.

Пример 1.1. Разбивание строки на массив строк.

String data = "192.168.1.1; 127.0.0.1; 169.254.165.1";

String[] res = data.split(";\\s*");

В результате мы получим массив из трех строк: res[0] = 192.168.1.1, res[1] = 127.0.0.1, res[2] = 169.254.165.1.

Пишем свои equals() и hashCode() методы

Каждый java-разработчик рано или поздно сталкивается с необходимостью переопределения метода equals, а соответственно и hashCode(). Кто-то пишет их сам, кто-то использует прибамбасы среды разработки. Например, я частенько использовал автоматическую генерацию в среде IDE Intellij IDEA (ALT + Insert / equals() and hashCode()), пока не нашел "красивое" решение, реализованное в библиотеке org.apache.commons - HashCodeBuilder() и EqualsBuilder().

Конечно, кто-то скажет, зачем использовать какие-то дополнительные библиотеки и классы, когда все можно самому написать. Ну, что сказать, на вкус и цвет...

Lazy Init или принцип Open session in view

В самом начале своего нелегкого пути по изучению Hibernate и фреймворка Spring для Java столкнулся с проблемой возникновения некого LazyInitException, когда пытался получить некий объект, ссылку на инстанс которого содержал другой, полученный от хибернейта.

Как всегда, горел очередной проект и читать документации особо было некогда, поэтому, пробежавшись быстро по поисковикам, уловил основной смысл данного поведения - при описания меппинга одного объекта по-умолчанию все его связи с другими объектами воспринимаются Hibernate как "ленивые". Иными словами, при наполнении данными объекта Group, который, к примеру, содержит в себе List users и связан с таблицей USER как One-To-Many, Hibernate не пойдет по этой связи наполнять данными список. Сделает он это лишь тогда, когда мы обратимся к этому списку. Здесь то и кроется корень проблемы - в моем приложении обращение к списку шло в тот момент, когда хибернейт сессия работы с базой, в которой я получил объект Group была уже закрыта. Отсюда и LazyInitException.

Запуск своего приложения на iPhone

Во время разработки программного обеспечения под iPhone столкнулся со следующей проблемой. Стандартная среда разработки позволяет запускать приложение на эмуляторе телефона, либо на самом аппарате (дабы была возможность протестировать все на реальной платформе). Так вот, если выбрать второй вариант, среда разработки попытается поставить созданное приложение на телефон и тут то и начинаются проблемы. Сначала Xcode дал критическую ошибку на тему того, что не задан какой-то сертификат. Выяснилось, что чтобы получить данный сертификат необходимо отстегнуть Apple минимум 100 баксов!

Форматирование чисел с помощью JSTL

1. Форматирование чисел в денежных форматах:

<%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt"%>

<fmt:formatNumber value="${account.balance}" type="currency" currencySymbol="&euro;" />

2. Форматирование по шаблону

<%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt"%>

<fmt:formatNumber value="12" pattern="###.##"/>  <!-- выдаст 12 -->

<fmt:formatNumber value="12.00" pattern="###.##"/>  <!-- выдаст 12 -->

<fmt:formatNumber value="12.011" pattern="###.##"/>  <!-- выдаст 12.01 -->

<fmt:formatNumber value="12.0066" pattern="###.##"/>  <!-- выдаст 12.01 -->

<fmt:formatNumber value="12.999" pattern="###.##"/>  <!-- выдаст 13 -->

<fmt:formatNumber value="12.1" pattern="###.00"/>  <!-- выдаст 12.10 -->

<fmt:formatNumber value="12" maxFractionDigits="5" minFractionDigits="2"/>   <!-- выдаст 12.00 -->

<fmt:formatNumber value="12.123456789" maxFractionDigits="5" minFractionDigits="2"/>   <!-- выдаст 12.12345 -->