Sziasztok!
Van egy .apk, aminek a kódjában ki szeretnék cserélni egy konstans értéket. apktool d, majd apktool b, de sajnos az .apk nem működik megfelelően. A dex file-ok mérete sem ugyanakkora lett... Létezik-e valamilyen olyan módszer, ahol egy .dex file-t olyan formátumra hozok, ahol hexa formában megtalálom az adott értéket és simán átírom, majd vissza tudom rakni .dex-be ?
Van egy Stateless beanem
@Stateless
public class IdsMB extends BaseMBData implements Serializable {
public int getId(String kodtar) {
String SQL = "SELECT i FROM Ids AS i WHERE i.id=...
EntityManager entityManager = getEntityManagerFactory().createEntityManager();
try {
entityManager.getTransaction().begin();
ids = entityManager.createQuery(SELECT_KODTARAK).getResultList();
......
id = entityManager.merge(id);
entityManager.getTransaction().commit();
} catch (Exception ex) {
logger.error(ex.getMessage(), ex);
try {
entityManager.getTransaction().rollback();
} catch (Exception e) {
logger.error(e.getMessage(), e);
}
}
entityManager.close();
return id.getSzam();
}Ez teljesen jól működik.
Amint hívásra kerül egy @Singleton beanben
@ManagedBean(name = "valami")
@ApplicationScoped
@Singleton
public class valami
public void status(){
IdsMB idsMB = new IdsMB();
idsMB.getId();
}
A singleton-on belül látszólag jól működik, nem dob kivételt mentéskor, a felette lévő select is jó adatot olvas mikor újra rá kerül a vezérlés, de az adatbázisban semmi nincs meg ebből?
Mi lehet ennek az oka?
Sziasztok.
Az alkalmazásban eddig "kézzel" kezeltük a tranzakciókat, EntityManagereket. Szeretnénk fokozatosan átállni a konténer által kezelt tranzakciókra és az EntityManager-t is injektálni szeretnénk..
A persistence.xml tartalma
<persistence-unit name="PU" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>jdbc/dtabase</jta-data-source>Van egy ősosztály, ebben egy
EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory(Constants.PERSISTENCE_UNIT_NAME);
public EntityManagerFactory getEntityManagerFactory() {
return entityManagerFactory;
}Ezt leszármaztatva az örökölt osztályokban ezzel szerezzük meg az EntityManager-t.
EntityManager entityManager = getEntityManagerFactory().createEntityManager();
entityManager.getTransaction().begin();
entityManager.merge(valami);
entityManager.getTransaction().commit();Most, ki szerettük volna próbálni, hogy a konténer kezelje a dolgokat, így próbaképpen egy egyszerű funkciót szerettünk volna megvalósítani. De amint bekerül egy
@PersistenceContext(name = "PU")
private EntityManager em;annotáció a kódba, az eddigi megoldásokra futás időben "Cannot use an EntityTransaction while using JTA." hibaüzenetet kapunk.
A két módszert egyszerre lehet használni? Ha igen hogyan?
A használt környezet: JavaEE, GlassFish, EclipseLink
Van egy szerverem. Java 11-re nemrég tértünk át, és az egyik szerver megbokrosodott.
Eddig beérte max. 5-6G memóriával, most hirtelenjében annyit eszik amennyit csak tud.
Ha készítek belőle memory dumpot, pl. egy 23G-ás RES memória foglalásról, akkor a profiler azt mondja, hogy az élő objektumok mérete 1G alatti. Mi a fene lehet a másik 22G?
Ötletek?
UPDATE:
A heap memórián az élő objektumok 900 mega körül vannak. Ezen kívül van még 22 (most már ~30) giga valami még.
Azaz mivel lehetne kideríteni, hogy mi az ami a heap-on kívül eszi a memóriát?
Sziasztok,
Van egy hiba az IntelliJ IDEA-ban ami engem elegge idegesit. Sajnos csak akkor kezdenek vele valamit, ha elegen szavaznak ra.
Akinek mar van account-ja naluk, esetleg szavazhatna ra. Akinek nincs, de azert megis segitene, csak regisztraljon. Koszi!
Van egy adatbázis amiben van egy több mint 10 millió rekordot tartalmazó tábla.
Java oldalon egy ugyan ennyi entitásból álló ArrayList reprezentálja ezt az adathalmazt
Egy üzleti logika minden egyes entitást módosít majd ezek visszaírásra kerülnek a JPA által az adatbázisba. Na ez tart irdatlan sokáig. Több mint egy óra amíg ez a bő 10 millió update megfut.
Elég sok mindent kipróbáltam már. Egy tranzakcióval, x rekordonként külön tranzakcióval, entitymanager.flush() meghívásával de nem javult érdemben a teljesítmény.
EclipseLinkben bekonfiguráltam a batch-write opciót is de így sem. És ez a több mint egy órás időtartam agyrém főleg úgy, hogy egy teljes adatbázismentést ami a mysqldumppal készült és benne van ez a 10 millió rekord kb. 3 perc alatt visszatölt.
Ha esetleg valakit érdekel, akkor összedobtam egy Java klienst, amivel kényelmesen el lehet érni a Billingo szolgáltatásait API-n keresztül.
Nagyjából minden megy, kivéve az "Invoice Query", a "Recurring" és a "Products" végpontok. De ezek is nemsokára elkészülnek.
Vélemény, javaslat, ötlet és hiba jöhet GitHub szokás szerint issue vagy pull request formájában.
A szoftverfejlesztés nem szakma: nincsenek olyan általánosan elfogadott szabályai, amik betartása esetén valószinűleg nem fogod elrontani.
Elkezdtünk hát azon gondolkodni, hogyan nézne ki a fejlesztés, ha szakma lenne.
Megmutatjuk, hol tartunk a gondolkodásban, és mit fogunk csinálni, hogy ellenőrizzük a hipotéziseinket.
https://www.meetup.com/Budapest-Kode-Konveyor-Meetup-Group/events/26442…
Sziasztok!
Azt kellene valahogy elérnem, hogy egy user egy időben csak egy helyről lehessen bejelentkezve.
Tehát ha A eszközről be van jelentkezve a user majd átmegy a B eszközhöz és onnan bejelentkezik akkor A eszközről dobja ki. Természetesen a session lejárati időnek továbbra is meg kell maradnia.
Van erre valami gyári támogatás, vagy hogy lehet ezt megoldani?
A lényeg, hogy kapok számsorokat.
Ezeket kell 4 kategóriába sorolnom.
Erre csak érzésem van, hogy melyik hova tartozzon:
Példák:
----------------
1, 1, 3, 3, 4, 11, 34 -->
1, 1 -> 1.
3, 3, 4 -> 2.
11 -> 3.
34 -> 4.
----------------
1, 13, 25, 68, 1191 -->
1 -> 1.
13, 25, 68 -> 2.
-> 3. (üres)
1191 -> 4.
----------------
0, 0, 0, 31, 68, 230, 411, 1511, 2034 -->
0, 0, 0 -> 1.
31, 68 -> 2,
230, 411 -> 3.
1511, 2034 -> 4.
----------------
0, 1, 5, 30 -->
0 -> 1.
1 -> 2.
5 -> 2. vagy 3.
30 -> 4.
Van valami ötletetek, hogy miként lehetne programozottan?